2010-08-25 14 views
0

J'ai un problème étrange, relatif à l'exécution d'un script BASH via cron (invoqué via crontab -e).Comment puis-je empêcher crontab de perturber ce simple script BASH (et pourquoi cela se produit-il)?

est le script ici:

#!/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 

Effectué à partir de la ligne de commande, je reçois la sortie attendue de 45:70 fait écho à la fin du fichier texte. Cependant, quand je lance le script via Cron (en utilisant crontab -e) et l'entrée suivante:

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

Je reçois juste deux points (:) écho au fichier texte, les valeurs SIG1 et SIG2 aren » t créé et je ne sais pas pourquoi. Pourquoi courir via cron gâcher le script?

FWIW, voici la sortie de iwconfig wlan0 sans traitement supplémentaire:

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 

que je fais tout cela parce que je veux afficher le WiFi Link valeur de qualité « 46/70 » sur un écran LCD et le programme que j'utilise fait cela en lisant un fichier texte. Cependant, lorsqu'il est exécuté via cron, les valeurs se perdent ... ??? J'utilise cut -c 9-10 et cut -c 12-13 parce que je pensais que le "/" pourrait causer un problème dans le script, je serais heureux d'utiliser cut -c 9- 13, mais je pensais que cela pourrait régler le problème, mais ce n'était pas le cas.

Aide !! Cool, merci à vous les gars, je me suis rendu compte que c'était un problème PATH, en donnant simplement le chemin complet à iwconfig (/ sbin/iwconfig) l'a corrigé. Voici une photo de l'écran LCD montrant maintenant toutes les informations correctes:

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

+0

Il est recommandé de démarrer un script bash avec le commutateur '-e' ou de le placer sur la ligne shebang. De cette façon, il interrompt le script sur la première commande qui échoue, vous donne le numéro de ligne de commande qui a échoué et permet d'éviter la corruption de données due à une commande précédemment échouée. –

Répondre

2

Vous devez indiquer le chemin d'accès complet aux commandes exécutées via cron. cron exécute des commandes détachées de tout terminal, ce qui signifie que vous devez définir correctement l'environnement. la coupure est probablement disponible mais donne le chemin absolu à iwconfig et à awk

+0

C'est une bonne pratique, pas nécessaire, non? – Jasper

+0

Vous avez raison, il fallait le chemin complet vers iwconfig, je n'ai jamais su! Salutations – prupert

+0

heureux d'avoir aidé, et oui vous donnez des chemins absolus à toutes les commandes exécutées via cron (ou juste comme meilleure pratique dans un script shell) – ennuikiller

0

Modifier l'autorisation de ce fichier à 777

chmod 777 /home/rupert/test.sh 

Peut-être que cela vous aidera.

+0

Il ne me semble pas que le test ait des permissions incorrectes (il est en cours d'exécution ...), mais que le problème d'autorisation est avec iwconfig. – Jasper

+0

Oui, je pense que les autorisations sur le fichier .sh sont correctes, car il fonctionne (utilisé chmod a + x), mais comme Jasper l'a dit, cela peut être un problème avec iwconfig .. – prupert

+0

Vous ne devriez presque jamais changer les permissions de * n'importe quel * fichier à 777. –

0

Je ne connais pas les étapes exactes pour empêcher cela (de manière propre) de se produire (je ne suis pas tout à fait un expert linux), Cependant, cela ressemble à un problème de permissions pour moi. L'utilisateur qui exécute les tâches cron n'est pas autorisé à exécuter l'une des commandes que vous laissez exécuter.

Si vous corrigez les permissions, je pense que ça peut fonctionner correctement!

+0

Pas un problème de permission, il s'est avéré que c'était un problème PATH;) – prupert

+0

C'est l'autre problème qui est possible dans cron vs CLI (disclaimer: que je connais), je ne pensais tout simplement pas que c'était un problème ici. – Jasper