Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: tetsujin@scope-eye.net
Newsgroups: gnu.bash.bug
Subject: Re: Directing into a variable doesn't work
Date: Wed, 27 Jun 2018 15:03:24 -0400
Lines: 43
Approved: bug-bash@gnu.org
Message-ID: <mailman.2641.1530126213.1292.bug-bash@gnu.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: chet.ramey@case.edu
To: chet.ramey@case.edu, "Peter Passchier" <peter@passchier.net>, "Martijn Dekker" <martijn@inlv.org>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
in-reply-to: <1572c54e-5756-9ad4-a195-c9fa681f9810@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:14282

=0A=0AWhen I initially read this thread, I was concerned about the idea=
 of=0Aadding yet another mutation of the redirect syntax.=0ALike how far=
 does this go? Would we introduce a ">>>>" someday for=0Asome other bit=
 of functionality?=0A=0AIdeally, I think it would be better if this coul=
d be done with pipe=0Asyntax and builtins=0A(so that instead of introduc=
ing another redirect syntax for "capture=0Ato variable",=0Awe instead pi=
pe to the already-existing "read" command)=0AThis would also allow for u=
sing the built-ins to specify options like=0Adelimiters, how much to rea=
d, allow for reading=0Ainto an array, and so on, and without diving deep=
er into increasingly=0Aexotic syntax.=0A=0AHowever adding support for co=
nnecting separate pipes to stdout and=0Astderr and a generalized version=
 of "lastpipe"=0Athat can handle multiple builtins within the same job w=
ould be a=0Apretty big undertaking. It'd probably mean threading=0Aand t=
hread-safety, and of course some strategy for tying that into job=0Acont=
rol.=0A=0AFor what it's worth, I think I have a real use case for this p=
roposed=0Asyntax.=0AI'm working on loadable modules to do things like op=
en Unix Domain=0ASockets and so on.=0AThe general form of these things (=
so far) is open the file=0Adescriptors, and then store the FD numbers in=
 a variable.=0AI think a better pattern would be "open the file descript=
ors, and=0Awrite their FD numbers to stdout" - and then capture them.=0A=
Of course in Bash this wouldn't work via command substitution:=0A=0Afd=
=3D$(connect_to_socket "$socket_path")=C2=A0=C2=A0 # Command subst. is a=
=0Asubshell, so file is opened but lost=0A=0AHowever, with a "capture-to=
-variable" redirect, this pattern would=0Awork:=0A=0Aconnect_to_socket "=
$socket_path" >>> socket_fd_var=0A=0AMore generally, it solves the probl=
em of how to capture output from a=0Acommand that must also modify the=
=0Ashell's environment.=0A=0AWhile it's essentially syntactic sugar (and=
 despite my concerns about=0Afurther overloading the redirect operators)=
=0AI think I'm starting to see the value in it.=C2=A0 I can't promise=0A=
anything at this point but I'd like to see what I can come=0Aup with.=0A=
----- Original Message -----=0AFrom: chet.ramey@case.edu=0ATo:"Peter Pas=
schier" <peter@passchier.net>, "Martijn Dekker"=0A<martijn@inlv.org>, <b=
ug-bash@gnu.org>=0ACc:<chet.ramey@case.edu>=0ASent:Mon, 25 Jun 2018 09:1=
1:45 -0400=0ASubject:Re: Directing into a variable doesn't work=0A=0A On=
 6/24/18 11:26 AM, Peter Passchier wrote:=0A > Thank you for the feedbac=
k, very insightful. Yes, scratch that=0Afirst=0A > 'example'. Yay for th=
e here-variable redirection!=0A=0A The answer is ultimately the same as=
 it was last month:=0A=0A http://lists.gnu.org/archive/html/bug-bash/201=
8-05/msg00056.html=0A=0A(from link:)=0A=0AWhat you're asking for is synt=
actic sugar for: =0A=0A=09some-command > temp-file =0A echo '#' >> temp-=
file =0A variablename=3D$(< temp-file) =0A rm -f temp-file =0A variablen=
ame=3D${variablename%?} =0A=0A I would look at a sample implementation,=
 possibly using mmap, if=0Asomeone =0A did one.=0A=0A