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?
