Calling this a "bug" seems unfair since it really falls in the category of "Don't Do That!" or more likely, "Only an idiot would do that!" None the less, I'm curious how you would classify this unexpected behavior.
The 'while read VAR; do ...; done < file.txt' construct has a somewhat odd behavior in ksh when lines within the input file contain a backslash followed by a space (or possibly other typically escaped characters). Setting the Internal Field Separator (IFS) has no effect, and similar is true for using printf(1) rather than echo(1). The "problem" (if you can call it that), is in the read'ing itself trying to un-escape the backslash-space combination. I'm guessing there is most likely some reason for the un-escaping deep in the very complex interactions of the shell/system, but sadly, I can't think of it. If you happen know why, plueesse kick the knowledge downstairs to the unwashed. ******************************************************************* #!/bin/ksh echo "" echo "Create a messed up directory name with backslash." echo 'mkdir "d\ 4"' mkdir "d\ 4" echo "" echo "touch(1) some files in the messed up directory." touch "./d\ 4"/f0.txt touch "./d\ 4"/f1.txt touch "./d\ 4"/f2.txt echo "" echo "Print actual path/filename with find(1)" find "./d\ 4"/ -type f -print echo "" echo "Save the find(1) output of actual path/filename to a file." find "./d\ 4"/ -type f -print >files.txt echo 'cat files.txt' cat files.txt echo "" echo "Show how 'while read LINE; do ...; done < files.txt' fails." while read LINE; do echo $LINE done < files.txt; echo "" echo "Note the missing backslash." exit 0 ******************************************************************* -- J.C. Roberts
