[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: builtin "read -d" behaves differently after "set -e#
From: |
DJ Mills |
Subject: |
Re: builtin "read -d" behaves differently after "set -e# |
Date: |
Wed, 6 Feb 2013 13:44:04 -0500 |
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!