2010-08-25 2 views
0

У меня есть странная проблема, связанная с запуском скрипта BASH через cron (вызывается через crontab -e).Как я могу остановить crontab от испортить этот простой скрипт BASH (и почему это происходит)?

Вот сценарий:

#!/bin/bash 

SIG1="$(iwconfig wlan0 | awk '/Quality=/ { print $2} ' | cut -c 9-10)" 
SIG2="$(iwconfig wlan0 | awk '/Quality=/ { print $2} ' | cut -c 12-13)" 

echo "$SIG1:$SIG2" >> test.txt 
exit 

При запуске из командной строки, я получаю ожидаемый выход 45:70 вторит до конца текстового файла. Однако, когда я бегу сценарий через хрон (с использованием кронтаб -e) и следующая запись:

* * * * * bash /home/rupert/test.sh

Я просто двоеточие (:) вторит в текстовый файл, то значения SIG1 и sig2 Арен» т, и я понятия не имею, почему. Зачем запускать через cron беспорядок скрипта?

FWIW, вот выход iwconfig wlan0 без дополнительной обработки:

wlan0  IEEE 802.11abgn ESSID:"plumternet" 
      Mode:Managed Frequency:2.452 GHz Access Point: 00:18:84:2A:68:AD 
      Bit Rate=54 Mb/s Tx-Power=15 dBm 
      Retry long limit:7 RTS thr:off Fragment thr:off 
      Power Management:off 
      Link Quality=46/70 Signal level=-64 dBm 
      Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 
      Tx excessive retries:0 Invalid misc:0 Missed beacon:0 

Я делаю все это, потому что я хочу, чтобы отобразить WiFi Link значение качества «46/70» на ЖК-экране и программа, которую я использую, делает это, читая текстовый файл. Однако при запуске через cron значения теряются ... ???

Я использую cut -c 9-10 и cut -c 12-13, потому что я думал, что «/» может вызвать проблему в скрипте, я был бы рад просто использовать cut -c 9- 13, но я подумал, что это может решить проблему, но это не так.

Справка!

Прохладный, спасибо вам, ребята, я понял, что это проблема PATH, просто давая полный путь к iwconfig (/ sbin/iwconfig), исправил его. Вот ПИК ЖК-экран теперь показывает все правильно данные:

http://img835.imageshack.us/img835/4175/20100825122413.jpg

+0

Это хорошая практика, чтобы запустить скрипт bash с помощью переключателя '-e' или поставить его на линию shebang. Таким образом, он прерывает выполнение сценария первой неудавшейся команды, дает вам номер неудавшейся командной строки и, возможно, помогает избежать повреждения данных из-за ранее неудавшейся команды. –

ответ

2

Вам необходимо предоставить полный путь к любым командам, выполняемым через cron. cron запускает команды, отсоединенные от любого терминала, что означает, что вам нужно правильно настроить среду. разрез, возможно, доступен, но дает абсолютный путь к iwconfig и awk.

+0

Это хорошая практика, не нужно, правильно? – Jasper

+0

Вы правы, ему нужен полный путь к iwconfig, я никогда не знал! Cheers – prupert

+0

рад помочь, и да вы даете абсолютные пути ко всем командам, выполняемым через cron (или как наилучшая практика в любом сценарии оболочки) – ennuikiller

0

Изменить разрешение этого файла 777

chmod 777 /home/rupert/test.sh 

Может быть, это поможет.

+0

Мне не кажется, что тест имеет неправильные разрешения (это _ис_ работает ...), но проблема разрешения с iwconfig. – Jasper

+0

Да, я думаю, что разрешения на файл .sh в порядке, так как он работает (используется chmod a + x), но, как сказал Джаспер, это может быть проблема с iwconfig .. – prupert

+0

Вы почти никогда не должны изменять разрешения * любой * файл до 777. –

0

Я не знаю, какие именно меры были предприняты для предотвращения этого (в чистом виде) (я не только специалист по Linux) однако это выглядит как проблема с разрешениями для меня. Пользователь, выполняющий задание cron, не может выполнять одну из команд, которые вы разрешаете выполнить.

Если вы исправите разрешения, я думаю, что это может работать просто отлично!

+0

Не проблемы с разрешением, оказывается, это проблема PATH;) – prupert

+0

Это еще одна проблема, которая возможна в cron vs CLI (отказ от ответственности: что я знаю), я просто не думал, что это проблема. – Jasper

Смежные вопросы