Re: builtin "read -d" behaves differently after "set -e#

[Dan Douglas]

On Wednesday, February 06, 2013 01:44:04 PM DJ Mills wrote:
> On Tue, Feb 5, 2013 at 6:39 PM, Tiwo W. <tiwocode@gmail.com> wrote:
> 
> >         I have seen "read -d '' var" to read multi-line heredocs into
> >         shell variables. An empty argument to -d seemed to mean "read
> >         up to the end of input". And this is what it does.
> >
> >
> In addition to all of the "don't use set -e" answers you've gotten (which i
> agree with wholeheartedly), I have this to add:
> 
> read -rd '' is synonymous to read -d $'\0'. It doesn't actually mean "read
> until the end of input", but rather "read until a NUL byte is encountered".
> You see this usage a lot as well when reading NUL-delimited data, say
> filenames from find. For example:
> 
> while IFS= read -rd '' file; do
>   some_command "$file"
> done < <(find . -type f -print0)
> 
> So what's actually happening with your here document usage case is that
> read is looking for a NUL byte, but never finds one, so it stops reading
> when EOF is encountered. As Greg mentioned, this then casuse read to exit >
> 0. This is a perfectly acceptable usage, but now you know why that happens.
> 
> And to reiterate, STOP USING set -e!

+1 to all of that.

Note $'\0' was used here for illustration and doesn't actually expand to a nul 
byte. To be completely clear, the command: `read -rd '' x' is literally 
receiving the same arguments as the $'\0' case -- it's not only that `read' is 
treating them the same.

Also, if it means anything, sadly ksh93 didn't perform that termination until 
one of the most recent alphas. I take it that this is sort of an extra special 
feature that most shells with -d happen to share, and not merely a necessary 
consequence of -d with an empty arg. 

Hopefully someday `mapfile' will inherit an analogous feature.
-- 
Dan Douglas