Re: `read' builtin does not take last record without trailing delimiter

[Jan Schampera]

Scott Mcdermott wrote:
> Bash does not seem to take the last record if it has no
> trailing delimiter:
> 
> 
>     $ echo "0 1 2^3 4 5^6 7 8" |
>       while read -a array -d ^
>       do echo $array
>       done
>     0 3

> This behavior is counter-intuitive.  It just throws away the
> last line and it's never even put into the array.  I think
> the whole intention of using read to split lines by
> delimiter is always to read the last line even though it has
> a trailing null or newline instead of a delimiter, just like
> awk does.

It's not 'read' directly, it's the exit code of 'read'. The value is
read and the array is set correctly, it's just the trigger for the
'while' loop that's missing (because of the exit code of 'read').

> 
> IMO this is a bug but I'm sure this behavior is known and I
> am wondering at its rationalization? I don't see any
> arguments about it in the archives, this is just accepted?
> It seems silly for a script to always have to take care to
> add a delimiter even if the input doesn't have one, as is
> extremely common (perhaps even universal).  At the very
> least I think an option should be present to turn on this
> behavior for the builtin, because I can see some cases where
> one *would* want the behavior as implemented as well.

I'm sure Chet accepts patches, if he thinks it's a bug. I'm not sure if
it's a bug per se, but at least it's a usability issue to discuss. Maybe
it can be reduced to "read reacting on EOF" - and yes, the current
behaviour of reaching EOF is documented in the manual, and personally
I'm fine with it.

J.