0
if [ $(/sbin/iptables -w -L INPUT -n|grep --line-buffered -m 1 -c -w 66.128.56.213) == "0" ]; then /sbin/iptables -w -I INPUT "$(/sbin/iptables -w -L INPUT -n --line-numbers|stdbuf -o0 grep -m 1 -w DROP|stdbuf -o0 awk  '{print $1}')" -i eth0 -s 66.128.56.213 -m comment --comment 'kern.log Oct 27 23:14:10 PROTO=UDP SPT=5118 DPT=5060' -j DROP;fi

Ubuntu headless 15.10: The above statement was scheduled in 'at' by my script I am developing. It did not do the expected iptables insert task when it ran because the comparison within the brackets is false (I used an else, not shown, to learn that). I have tried changing the quoting of the zero...no quotes, single quotes and double quotes. I know the value prior to the '==' is 0 because I inserted this in the constructed, scheduled command prior to what is shown above: echo $(/sbin/iptables -w -L INPUT -n|grep --line-buffered -m 1 -c -w 66.128.56.213) >> /home/mydir/testfile.txt

and it echo'd a simple 0 into the file. And if I just try 0 == 0 in the brackets, it computes as false also. Can anyone see why I can't compare two zeros to be the same as each other? And how can I make my desired statement branch the way I want it to: when the substituted command equates to zero? It acts differently, and correctly as expected, from the command line. My guess is a shell difference. I tried using double brackets. No luck. ([]) doesn't work, either. Neither does using eq in place of ==.

hlovdal
  • 26,565
  • 10
  • 94
  • 165
kenneth558
  • 89
  • 8
  • I discovered that simply evaluating the substituted command inside the brackets (it will either be 0 or 1) and not compare it might work for me. Trying now, no success yet.... – kenneth558 Oct 28 '15 at 07:47

2 Answers2

0

Running from at you have no controlling terminal, and quite possibly iptables changes its output format. The fact you need --line-buffered on grep indicates something is wrong.

Instead, uses iptables-save which produces a predictable machine-parseable output format.

abligh
  • 24,573
  • 4
  • 47
  • 84
  • Let's say between you and me that I don't really need line-buffer. The real problem is the comparison. How can I compare two equal things to be true? Command line makes it work, 'at' scheduling breaks it. The comparison, that is. That is my challenge, not the fact that I'm forming the iptables commands different than you would, or inserting iptables commands different. They function fine for what I want done. Thanks for giving it a shot, though. Try again? (focusing on the difference in how to compare for the 'if' statement between interactive and run from scheduled) – kenneth558 Oct 28 '15 at 07:25
  • I suspect you will find if you run the `grep` through `tee` and put it's output into a file, it is actually producing different output. Put `iptables` through `tee` as well, and determine whether it is producing different output. – abligh Oct 28 '15 at 07:50
0

@abligh, Thank you for trying. The answer is found in the warning that you'll only see when loading 'at' commands interactively:

`warning: commands will be executed using /bin/sh'

Correct syntax for this in /bin/sh is:

if [ $(/sbin/iptables -w -L INPUT -n|grep --line-buffered -m 1 -c -w 66.128.56.213) -eq 0 ]; then...

The grep output is numeric, not text, so quotes are removed, and the '==' is replaced by '-eq', and the 'if' is optional.

kenneth558
  • 89
  • 8