hello, I wanted to play around with this idea, and see how it works. Quick and dirty patch (against devel@c181950a89c0f0ca4a3ae2480b783da2f7de9565) is attached. Just modified parser and hardcoded tempfile /tmp/v_save.bash.temp. result:
bash-5.0$ echo 'hello a' >>> a; echo $a hello a If you don't mind we can get it off the list, and see if we can workout a better way to bind data from redirection with variable, and come up with something. If not, maybe you will find something useful in this patch, I have no idea if I will be able to present any decent version of it. cheers, pg
store_result_in_varible_quick_and_dirty.diff.patch
Description: Binary data
On 27 Jun 2018, at 21:03, tetsu...@scope-eye.net wrote: > > > 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.ra...@case.edu > To:"Peter Passchier" <pe...@passchier.net>, "Martijn Dekker" > <mart...@inlv.org>, <bug-bash@gnu.org> > Cc:<chet.ra...@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. > >
