Hi, drewk:

No offense taken. I was just making sure that my response didn't come across as petty. So, now that we're done being nice, back to business

I don't use bash very often so I've never used that read option before. Usually, in similiar situations I make do with xargs. However, looking at it, I spot two bugs (ironically, one of them is a field splitting bug) in that code. Check it out:

Code:

#Create a directory whose name begins with leading spaces
$ mkdir '        8spaceslater'

#Place two files in that directory, with the first one ending in a backslash
$ touch \ \ \ \ \ \ \ \ 8spaceslater/1\\
$ touch \ \ \ \ \ \ \ \ 8spaceslater/2

#Now let's try that code
$ find '        8spaceslater' -type f -print0 | while read -d $'\0' file; do echo "$file"; done         
8spaceslater/1

What happened to the leading spaces? The leading spaces are lost during the field splitting step. Let's disable field splitting by setting IFS to an empty string:

Code:

$ find '        8spaceslater' -type f -print0 | while IFS='' read -d $'\0' file; do echo "$file"; done
        8spaceslater/1

Now that we got our leading white space through intact, what about the trailing backslash of "1\" and the second file, "2"? The backslash is consumed as part of an escape sequence which results in a null byte in $file, which is why the second file does not appear in the output (a nullbyte marks the end of a string in C). This backslash escape sequence processing can be disabled by passing read the -r option, which enables raw mode.

For maximum "robustness":

Code:

$ find '        8spaceslater' -type f -print0 | while IFS='' read -rd $'\0' file; do echo "$file"; done
        8spaceslater/1\
        8spaceslater/2

In this particular example, the only advantage to using null byte delimiters is proper handling of filenames containing linefeeds. If that's not an issue, nothing is gained.

Regards,
Alister