Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11886 > unrolled thread
| Started by | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| First post | 2015-11-16 08:41 -0500 |
| Last post | 2015-11-16 08:41 -0500 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: redirecting a file descriptor to an array variable? Possible? How? RFE? Greg Wooledge <wooledg@eeg.ccf.org> - 2015-11-16 08:41 -0500
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2015-11-16 08:41 -0500 |
| Subject | Re: redirecting a file descriptor to an array variable? Possible? How? RFE? |
| Message-ID | <mailman.26.1447704601.24003.bug-bash@gnu.org> |
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 top | Article view | gnu.bash.bug
csiph-web