tags:

views:

27

answers:

3

I have a strange issue, relating to running a BASH script via cron (invoked via crontab -e).

Here is the script:

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

When run from the commandline, I get the expected output of 45:70 echoed to the end of the text file. However, when I run the script via cron (using crontab -e) and the following entry:

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

I just get the colon (:) echoed to the text file, the values SIG1 and SIG2 aren't created and I have no idea why. Why would running via cron mess up the script?

FWIW, here is the output of iwconfig wlan0 with no additional processing:

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

I am doing all this because I want to display the WiFi Link Quality value "46/70" on an LCD screen and the program I use does this by reading a text file. However, when run via cron, the values get lost...???

I am using cut -c 9-10 and cut -c 12-13 because I was thinking the "/" might be causing an issue in the script, I'd be happy to just use cut -c 9-13, but I thought it might fix the issue, but it didn't.

Help!!

Cool, thanks to you guys, I realised it was a PATH problem, simply giving the full path to iwconfig (/sbin/iwconfig) fixed it. Here is a pic of the LCD screen now showing all the correct info:

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

A: 

Change the permission of this file to 777

chmod 777 /home/rupert/test.sh

Maybe this will help.

Wolfy
It doesn't seem to me that test has incorrect permissions (it _is_ running...), but that the permission problem is with iwconfig.
Jasper
Yeah, I think permissions on the .sh file are ok, as it does run (used chmod a+x), but as Jasper said, it might be an issue with iwconfig..
prupert
You should almost never change the permissions of *any* file to 777.
Dennis Williamson
+1  A: 

you need to give the full path to any commands executed via cron. cron runs commands detached from any terminal which means you need to set the environment correctly. cut is probably available but give the absolute path to iwconfig and awk

ennuikiller
That's good practice, not necessary, right?
Jasper
You are correct, it needed the full path to iwconfig, I never knew! Cheers
prupert
glad to have helped, and yes you give absolute paths to all commands executed via cron (or just as best practice in any shell script)
ennuikiller
A: 

I don't know the exact steps to prevent this (in a clean manner) from happening (I'm not all that of a linux-expert), however, this looks like a permissions problem to me. The user as which cron jobs run isn't allowed to execute one of the commands you are letting execute.

If you fix the permissions, I think it may run just fine!

Jasper
Not a permission problems, turns out it was a PATH problem ;)
prupert
That's the one other problem that's possible in cron vs CLI (disclaimer: that I know of), I just didn't think it was being a problem here.
Jasper