Re: Directing into a variable doesn't work

[tetsujin]

When I initially read this thread, I was concerned about the idea of
adding yet another mutation of the redirect syntax.
Like how far does this go? Would we introduce a ">>>>" someday for
some other bit of functionality?

Ideally, I think it would be better if this could be done with pipe
syntax and builtins
(so that instead of introducing another redirect syntax for "capture
to variable",
we instead pipe to the already-existing "read" command)
This would also allow for using the built-ins to specify options like
delimiters, how much to read, allow for reading
into an array, and so on, and without diving deeper into increasingly
exotic syntax.

However adding support for connecting separate pipes to stdout and
stderr and a generalized version of "lastpipe"
that can handle multiple builtins within the same job would be a
pretty big undertaking. It'd probably mean threading
and thread-safety, and of course some strategy for tying that into job
control.

For what it's worth, I think I have a real use case for this proposed
syntax.
I'm working on loadable modules to do things like open Unix Domain
Sockets and so on.
The general form of these things (so far) is open the file
descriptors, and then store the FD numbers in a variable.
I think a better pattern would be "open the file descriptors, and
write their FD numbers to stdout" - and then capture them.
Of course in Bash this wouldn't work via command substitution:

fd=$(connect_to_socket "$socket_path")   # Command subst. is a
subshell, so file is opened but lost

However, with a "capture-to-variable" redirect, this pattern would
work:

connect_to_socket "$socket_path" >>> socket_fd_var

More generally, it solves the problem of how to capture output from a
command that must also modify the
shell's environment.

While it's essentially syntactic sugar (and despite my concerns about
further overloading the redirect operators)
I think I'm starting to see the value in it.  I can't promise
anything at this point but I'd like to see what I can come
up with.
----- Original Message -----
From: chet.ramey@case.edu
To:"Peter Passchier" <peter@passchier.net>, "Martijn Dekker"
<martijn@inlv.org>, <bug-bash@gnu.org>
Cc:<chet.ramey@case.edu>
Sent:Mon, 25 Jun 2018 09:11:45 -0400
Subject:Re: Directing into a variable doesn't work

 On 6/24/18 11:26 AM, Peter Passchier wrote:
 > Thank you for the feedback, very insightful. Yes, scratch that
first
 > 'example'. Yay for the here-variable redirection!

 The answer is ultimately the same as it was last month:

 http://lists.gnu.org/archive/html/bug-bash/2018-05/msg00056.html

(from link:)

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.