Why a hard coded string var is changing when the bash script is run as root ?

Question

I am batch converting some pictures with a quick and dirty bash script using ufraw :

IFS=$'\n'
PICS="/media/disk/kevin/Images/";
for pic in $(find $PICS -name "*CR2");
do
    ufraw-batch $pic --out-type jpg --size=2048 --overwrite --out-path=$PICS;
    rm -f $pic
done;
IFS=" ";

It's running fine with the usual rights, but if I run it with :

sudo ./convert.sh

I got this strange error :

find: "/media/disk/kevi" : no such file or directory.

I made it :

IFS=$'\n'
PICS="/media/disk/kevin/Images/";
echo PICS;

Then I got surprisingly :

/media/disk/kevi /Images/

WTF ?

Answer 1

You're winding up with $IFS being "n"; it's not interpreting \n as a newline but as a meaninglessly escaped n. I vaguely suspect you're running into some sort of ill-documented protection of $IFS for root (since it's a well known exploit vector), but you might want to try embedding a literal newline instead of a symbolic one in your script using ctrl-v enter.

Answer 2

Your code seems to have a typo. If the actual code is IFS='\n' or IFS="\n", you've set the separator to a list of two characters, \ and n. If IFS=\n, then one char A POSIX shell doesn't interpret \n as LF. It has nothing to do with root.

$ BLAH='\n'
$ echo $BLAH
\n
$ BLAH="\n"
$ echo $BLAH
\n
$ BLAH=\n
$ echo $BLAH
n
$ BLAH="Both\n\and\aregone"
$ echo $BLAH
Both   a d arego e

Answer 3

If you don't have an explict #! line in your script, chances are that the sudo-ed command is being run under /bin/sh rather than /bin/bash and, if you're running on a recent Linux system, chances are that /bin/sh is dash rather than bash. The maintainers of dash maintain that IFS is not supposed to interpret escape sequences (see, for instance, here).

$ more convert.sh
IFS=$'\n'
PICS="/media/disk/kevin/Images/";
echo $PICS;
ps
$ ./convert.sh
/media/disk/kevin/Images/
  PID TTY          TIME CMD
30827 pts/0    00:00:01 bash
32042 pts/0    00:00:00 bash
32043 pts/0    00:00:00 ps
$ sudo ./convert.sh
/media/disk/kevi /Images/
  PID TTY          TIME CMD
32044 pts/0    00:00:00 sh
32045 pts/0    00:00:00 ps
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2009-08-06 19:10 /bin/sh -> dash

So the behavior you see is only indirectly related to running under root. You'd see the same if you explicitly used dash. And another way to work around the problem would be to include an explict #!/bin/bash in your script.