2011-05-24



One of the most annoying pitfalls in Unix  shell  programming  is
the while-read loop.

     while read line ; do
             # ...
     done

The construct becomes even more problematic as soon as you  start
using arrays (in those shells that support them). That is because
then you likely define variables in such a loop. This alone isn't
the  problem  but  it likely becomes a problem when the shell de-
cides to run the loop in a subshell. This may happen if the  loop
is  part  of a pipe line. All but the last component are executed
in subshells ... and the last component *may* also.

I admit that the example is stupid, but it shows the point  quite
well:

     date | while read line ; do
             d="$line"
     done
     echo "date: $d"

Dependent on the shell (and its version!) you use, $d will expand
to the date or to nothing (because it's not set).

Whenever it makes a difference if the loop is executed in a  sub-
shell  or  not,  try to avoid the pipeline and redirect stdin in-
stead:

     while read line ; do
             # ...
     done <file

Syntactically I'm a bit pissed off because I cannot write:

     <file while read line ; do
             # ...
     done

This feels more natural to me, thus I use this stdin  redirection
on the left side frequently for simple commands.


Maybe this becomes clear when I investigate into the  early  time
when control constructs had been commands ...



One more thing about the shell:

I found that /usr/bin/[ isn't a link  to  /usr/bin/test  which  I
would  have  expected.  This is true, at least for the GNU coreu-
tils. Their man page of test(1) includes:

     NOTE: [ honors the --help and  --version  options,  but
     test  does  not.   test  treats  each   of  those as it
     treats any other nonempty STRING.

And of course there is the different handling of the  last  argu-
ment  (`]'). But why two different programs and not just one? Can
someone explain?



http://marmaro.de/lue/        markus schnalke <meillo@marmaro.de>