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.
