Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11886

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Show key headers only | View raw

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.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: redirecting a file descriptor to an array variable? Possible? How? RFE? Greg Wooledge <wooledg@eeg.ccf.org> - 2015-11-16 08:41 -0500

csiph-web