[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Directing into a variable doesn't work

From: Piotr Grzybowski
Subject: Re: Directing into a variable doesn't work
Date: Thu, 28 Jun 2018 14:12:12 +0200


 I wanted to play around with this idea, and see how it works. Quick and dirty 
patch (against address@hidden) 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.


Attachment: store_result_in_varible_quick_and_dirty.diff.patch
Description: Binary data

On 27 Jun 2018, at 21:03, address@hidden 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: address@hidden
> To:"Peter Passchier" <address@hidden>, "Martijn Dekker"
> <address@hidden>, <address@hidden>
> Cc:<address@hidden>
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]