Cron запускает несуществующий вариант . sh script
Я нашел другое возможное решение. Я нашел это, копаясь в чьем-то репозитории git hub. Это использует python3, встроенный в модуль сокета.
Предпосылки:
- У вас есть работающий адаптер по адресу <adapter address>.
- У вас есть целевое Bluetooth-устройство по адресу <device address>.
- Устройство закреплено.
То есть можно использовать ту же точку, что и rfcomm.
$python3
>>> import socket
>>> sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM)
>>> adapter = '00:11:22:33:44:55' #<adapter address>
>>> device = '55:44:33:22:11:00' #<device address>
>>> sock.bind((adapter, 1))
>>> sock.connect((device, 1))
## If not pinned it will ask you. You can use/adapt the bluez simple-agent for headless pinning
>>> sock.send(b'hello\n')
>>> sock.recv(100)
>>> sock.close()
Это классическая проблема «гонись за своим собственным хвостом ».
Если задание cron выдает ошибку, cron отправит электронное письмо из учетной записи пользователя, в которой оно запущено, на адрес электронной почты, указанный в текущей конфигурации почты в системе.
Поскольку первым сценарием было уведомление по электронной почте, я предположил (ошибочное предположение, )что cron запускал какую-то странную «фантомную копию» сценария, но он просто выполнял свою работу.
Именно @kusalananda навел меня на правильный путь.
Что мне кажется любопытным, и причина, по которой я написал это как ответ, так это то, что cron никогда не говорил, что с новым скриптом что-то не так, за исключением того, что он не может отправить электронное письмо. Небольшой момент 22, где акцент был сделан не на том вопросе.
Это конечно не оптимальный ответ, но в этот раз это была sbk ошибка(S tupid B ehind K eyboard )...
Таким образом, извлеченный урок и, возможно, совет другим, всегда внимательно следить за информацией, которой нет в деле..