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

[Chris F.A. Johnson]

On 2008-02-24, 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
>
> In this sense it does not behave like awk:
>
>     $ echo "0 1 2^3 4 5^6 7 8" |
>       awk -v RS=^ '{print $1}'
>     0 3 6
>
> 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.
>
> 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.
>
> What do people think of this?

    I wouldn't use that method to populate an array.

echo "0 1 2^3 4 5^6 7 8" |
 {
   read line
   IFS=^
   array=( $line )
   printf "%s\n" "${array[@]}" 
 }

-- 
   Chris F.A. Johnson, webmaster         <http://Woodbine-Gerrard.com>
   ===================================================================
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
.