Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Greg Wooledge Newsgroups: gnu.bash.bug Subject: Re: redirecting a file descriptor to an array variable? Possible? How? RFE? Date: Mon, 16 Nov 2015 08:41:57 -0500 Lines: 54 Approved: bug-bash@gnu.org Message-ID: References: <564532BD.60801@tlinx.org> <20151113131735.GE27325@eeg.ccf.org> <56488802.10800@tlinx.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1447704602 31058 208.118.235.17 (16 Nov 2015 20:10:02 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash To: Linda Walsh Envelope-to: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <56488802.10800@tlinx.org> User-Agent: Mutt/1.4.2.3i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 139.137.100.1 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11886 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.