different results between crontab and running script manually

Question

I have a bash script that does this:

nmap -sn 192.168.0.1-255 | grep -Eo 192.168.0.{1,3\}[0-9] > new.txt
date >> network_log
echo ---------------------------- >> network_log
cat new.txt >> network_log

Scans the network, and appends results to file network_log with a timestamp. After running it manually, the network_log file looks like this:

Tue 13 Sep 2016 11:22:23 EDT 
---------------------------- 

192.168.0.1
192.168.0.2 
192.168.0.45

whereas the cronjobs produce the following outputs in my network_log file:

Tue Sep 13 17:46:00 EDT 2016
----------------------------

with no ip results. Note: the cronjob is running from root user so it has all the elevation it needs to scan the entire network.

have you tried your script with `sudo` to see if it's the cron or root user which makes a difference? — Jean-François Fabre, Sep 13 '16 at 21:54
I am actually running the script from both sudo cron and regular cron, and they are both producing the same incorrect output. I ran my script manually using sudo & regular mode, they produce the same correct output. — carrots, Sep 13 '16 at 22:02
check environment variable differences. And I would do `grep -Eo '192\.168\.0\.{1,3\}[0-9]'` (quoting) — Jean-François Fabre, Sep 13 '16 at 22:05
attempting to try that... getting this error for some reason: "grep: invalid repetition count(s)" — carrots, Sep 13 '16 at 23:10
Do you put those commands in crontab directly or you just call the script? — Leon, Sep 14 '16 at 07:43
Check the path to `nmap` with `type map` or `which nmap` and put the full path in your script. — Mark Setchell, Sep 14 '16 at 08:30
@Leon just saw these now, I call the script from the cronjob, and no others write to new.txt — carrots, Sep 22 '16 at 00:56

score 6 · Answer 1 · answered Sep 14 '16 at 08:51

6

Your script lacks a shebang, so it might run with different shells depending on a crontab or manual launch.

Add the following as first line in your script (replace bash with your current user shell if needed):

#!/usr/bin/env bash

Don't use /bin/bash as it's less portable than /usr/bin/env bash.

Also, crontab runs won't have the PATH variable. Print your path variable with:

echo $PATH

And add it as second line of your script like:

#!/usr/bin/env bash
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

This should ensure that your script runs in the same environment when run by crontab or manually.

answered Sep 14 '16 at 08:51

Orsiris de Jong

2,819
1
26
48

Thanks for this! It works now, could you provide me with a link or expand on why /bin/bash is less portable than /usr/bin/env bash – carrots Sep 22 '16 at 00:51
/bin/bash is linux specific whereas /usr/bin/env is supposed to exist on all unix systems. See http://stackoverflow.com/questions/16365130/the-difference-between-usr-bin-env-bash-and-usr-bin-bash for mre. – Orsiris de Jong Sep 23 '16 at 06:15

score 3 · Accepted Answer · answered Sep 14 '16 at 08:19

First of all, there are a couple of problems in your grep regular expression:

The repetition count ({1,3}) applies to its preceding atom (i.e. '.') rather than the next one (i.e. '[0-9]').
An unescaped dot ('.') in the regex matches any character, which hides the previous error. Your regex (192.168.0.{1,3}[0-9]) matches 192.168.0.123 as follows:
```
192.168.0 matches 192.168.0
.{1,3}    matches .12
[0-9]     matches 3
```
But it would also match the following strings:
```
192116810abc1
192.681.012.9
```

The correct regex must be 192\.168\.0\.[0-9]{1,3} and it must be quoted, so that bash passes it to grep literally:

grep -Eo '192\.168\.0\.[0-9]{1,3}'

Yet, the wrong regex can hardly explain the problem your are seeing with cron.

One problem may be that you are using a fixed name new.txt for your temporary file. If you do the same in your other scripts, or if you set up this cron job to run every minute while it takes nmap more than a minute to complete scanning the network, then new.txt may be overwritten at the wrong time.

Please fix your script as follows and check if the problem disappears:

#!/bin/bash

tmpfile="$(mktemp)"
trap "rm $tmpfile" EXIT
nmap -sn 192.168.0.1-255 | grep -Eo '192\.168\.0\.[0-9]{1,3}' > "$tmpfile"
date >> network_log
echo ---------------------------- >> network_log
cat "$tmpfile" >> network_log

Thank-you for all these suggestions, I would have never realized the tmpfile thing is alot better, especially since nmap does take a relatively long time to run. & thankyou for regex corrections — carrots, Sep 22 '16 at 00:55

different results between crontab and running script manually

2 Answers2