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


Groups > gnu.bash.bug > #14123

Re: Redirect to variable

From Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups gnu.bash.bug
Subject Re: Redirect to variable
Date 2018-05-21 10:54 -0400
Message-ID <mailman.169.1526914501.1292.bug-bash@gnu.org> (permalink)
References <07bb0d73-b90a-1cc9-0a1d-59568a602777@passchier.net> <7c54ea99-32b8-b09a-58cd-304e7c37a2f3@case.edu>

Show all headers | View raw


On Mon, May 21, 2018 at 10:12:43AM -0400, Chet Ramey wrote:
> On 5/20/18 10:21 PM, PePa wrote:
> > I would like to do something like this, where output gets redirected
> > into a variable:
> > 
> > some-command >>> variablename1 2>>>variablename2
> > 
> > command-with-many-output-descriptors >>> var1 3>>> var3 4>>> var4
> > 
> > The idea is not needing files to be created but to just use memory. Half
> > a year ago I posted this idea here, but didn't get any reply, maybe this
> > isn't the right place? Am I blacklisted??
> 
> It's not possible, in general, to open a file descriptor to an arbitrary
> block of memory, especially given file descriptor inheritance between
> processes.
> 
> What you're asking for is syntactic sugar for:
> 
> some-command > temp-file
> echo '#' >> temp-file
> variablename=$(< temp-file)
> rm -f temp-file
> variablename=${variablename%?}
> 
> I would look at a sample implementation, possibly using mmap, if someone
> did one.

More generally, I think he's looking for syntactic sugar to replace:

unset tmpfile
tmpfile[2]=$(mktemp)
tmpfile[3]=#(mktemp)
...
some-command 2>"${tmpfile[2]}" 3>"${tmpfile[3]}" ...
echo '#' >>"${tmpfile[2]}"
echo '#' >>"${tmpfile[3]}"
...
var2=$(<"${tmpfile[2]}") var2=${var2%?}
var3=$(<"${tmpfile[3]}") var3=${var3%?}
...
rm -rf -- "${tmpfile[@]}"

(Plus appropriate EXIT trap hook-adding-and-removing infrastructure.)
(Plus adding the missing mktemp command for most platforms.)

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


Thread

Re: Redirect to variable Greg Wooledge <wooledg@eeg.ccf.org> - 2018-05-21 10:54 -0400

csiph-web