read builtin oddity/bug in bash 3.2?

[Daniel Musgrave]

I have found a seeming inconsistency with the behavior of the read
builtin of bash (3.2.0(1)-release, also tested in 3.00.15(1)-release).
I'm working on a Centos 4.4 system (RedHat derivative).  Let me describe
the conditions that cause the bug in as much detail as I have discovered
thus far.

If the current working directory is /usr/bin (and only /usr/bin, I
think), and you use the 'while read var; do ... ; done < file' construct
inside a shell script, read appears to incorrectly set the value of var
when file contains a line that:

 * starts and ends with '[' and ']' characters, respectively; and
 * contains no whitespace (this condition tested with all alphanumeric
characters, as well as a few punctuation chars); and
 * contains one or more 'w' characters

If the line matches the above conditions and is echoed without being
quoted ($var, not "$var"), the result is the single character 'w'.  If 
the line is quoted while being echoed, it prints normally.  Similarly 
(and this is the kicker, in my mind), if the working directory isn't 
/usr/bin, this behavior does not occur, regardless of the quoting on $var.

Below is the sample script and file that I used to test this behavior. 
You'll have to change the location of the file it reads.

#!/bin/bash
#
# Strange read bash builtin behavior

echo -e "Bash version: $BASH_VERSION\n"

bug_dir=/usr/bin
other_dir=/usr/sbin

run() {
  cd $1
  echo "in $PWD"
  while read line; do
    [ "$line" ] && {
      echo -e "$line  =>  \c"
      echo $line
    } || echo
  done < ~/list
  echo
}

run $bug_dir
run $other_dir
exit 0

-----

[w]
[w ]
[ w]
[ w ]
[w][w]
[w][q]
[w [w]
[w [w]]
[www]
[w13]
[word]
[throw]
[away]
[award award]

-----


I have tried several values for other_dir, including /usr/sbin, /bin,
/sbin, /etc, and /home, all of which do not exhibit this behavior.

So, down to the real question.  Is this somehow intended behavior?  It
seems this only happens with 'w'; I tested all the remaining
alphanumeric characters, all of which worked fine.  Similarly, 'echo
[w]' produces the expected output of '[w]', and you can actually modify
the above code to test the value of $var to see that it indeed does
equal 'w' when the above error conditions are met.  Obviously this is a
surmountable problem, for it can be avoided by either changing the
working directory or quoting var when using it.  On the other hand, it 
seems that consistent behavior is probably desired, even if this is
corner of a corner case ;) .

Daniel Musgrave
Abodio Software
(206) 454-1024
dmusgrave@abodiosoftware.com