On Sun, Nov 15, 2015 at 05:26:26AM -0800, Linda Walsh wrote:
> Note that printf *can* print out nul bytes:
Yes, of course it can:
printf '\0'
This can be used to serialize an array into a file:
printf '%s\0' "${array[@]}" > file
And to read it back:
array=(); while IFS= read -rd '' x; do array+=("$x"); done < file
Or in bash-4.4:
mapfile -td '' array < file
> >printf "\"%c\"\n" $'\x00' |hexdump -C
$'\x00' is the same as ''. There's no need to be fancy.
> But contrary to the manpage under printf:
> " The -v option causes the output to be
> assigned to the variable var rather than being printed to the
> standard output. "
>
> printf does not print the output of the above into a var instead
> of stdout.
>
> Seems like that would be a bug?
The command you used above does not have '-v var' in it.
> If I am in a locale using UTF-16, there will be lots of 'NUL'
> chars if I view that output as binary -- so there has to be one
> or more ways to encode NUL bytes in a var such that they don't
> terminate the string.
I do not have access to a UTF-16 environment. Does bash even WORK
in such an environment? At all?
> If the issue of varables being able to contain any sequence of
> binary bytescould be solved, it might make it easier to solve
> the problem of streaming std[out/err] to a variable or an array.
I don't see the relation between these two issues. "Being able to
store NUL bytes in a string" has nothing to do with "being able to
capture stdout and stderr separately in shell variables" as far as
I can see.
Chet would have to introduce a new feature for the latter to be possible.
