Re: Trailing newlines disappear

[Greg Wooledge]

On Fri, Jun 09, 2017 at 09:22:58AM -0400, Chet Ramey wrote:
> On 6/9/17 8:06 AM, Greg Wooledge wrote:
> > imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n')
> > imadev:~$ declare -p a
> > declare -a a=([0]="foo" [1]="baz" [2]="quux")
> 
> There's no mystery here. Mapfile reads lines delimited by newlines --
> read(2) is happy to do that job. Shell variable values can't contain NULs;
> they never have been able to. The entire line read gets stored as the
> value, but since C strings are NULL-terminated, you just see the contents
> preceding the first NUL. Should mapfile silently drop the NULs?

I'm not requesting any changes.  I'm simply trying to show all of the
existing behaviors, and specifically the three different results that one
gets by using three different techniques to read a file into a variable.
(Either you get the entire file with all NULs removed; or you get the
file with each line truncated at the first NUL within that line; or you
get the file only up to the first NUL.)  That way, people can choose the
appropriate technique for the result they want.

If anything, the fact that $() drops NUL bytes is the surprising outlier.
But it's definitely too late to change that.  Remember how many people
bitched and complained when 4.4 added a warning?