On 6/9/17 8:06 AM, Greg Wooledge wrote:
> Actually, it looks like the mapfile variant also has its own... let's
> call it "idiosyncratic" NUL handling:
>
> imadev:~$ unset a
> imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n')
> imadev:~$ declare -p a
> declare -a a=([0]="foo" [1]="baz" [2]="quux")
>
> Where did "bar" go? Looks like mapfile loses the contents after a NUL
> byte within each line, but then subsequent lines are fine. (E.g. what
> you would get if you blindly called strcpy() for each line, with the
> source buffer possibly having multiple NULs.)
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?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
