Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14272 > unrolled thread

Re: Directing into a variable doesn't work

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Directing into a variable doesn't work Peter Passchier <peter@passchier.net> - 2018-06-24 22:26 +0700

#14272 — Re: Directing into a variable doesn't work

Thank you for the feedback, very insightful. Yes, scratch that first
'example'. Yay for the here-variable redirection!

I am surprised by the general internal usage of temporary files for
here-documents & here-strings, because (generally speaking) memory is
quite abundant, and here-strings and even here-documents are usually not
huge. I can see for memory-depleted systems this might be an issue, and
there are no definite guarantees about the eventual size that is
required, but (again, generally) this could all be done in memory. (And
how about storage-depleted systems??)

Peter


On 06/24/2018 05:38 PM, Martijn Dekker wrote:
> Op 24-06-18 om 05:08 schreef Peter Passchier:
>> With memory being abundant and filesystem access expensive, I want to
>> put stdout and stderr of a command into variables (without needing to
>> write to a file):
>>
>> output=$($command 2>>>errors)
> 
> This would not work even if the feature is implemented. The $(command
> substitution) forks a subshell process to execute the command in,
> because the main shell process needs a process it can set up a pipe
> with. So the 'errors' variable would only exist in that subshell process
> and would be lost as soon as the command substitution completes.
> 
>> Or:
>>
>> $command >>>output 2>>>errors
> 
> This form seems conceivable to me.
> 
> However, note that here-documents and here-strings internally use
> temporary files, so they do involve file system access. I'm not Chet,
> but I don't think that would be different for your proposed feature. So
> while this might be some nice syntactic sugar, I'm afraid you would be
> disappointed about the performance.
> 
> I still kind of like the idea, though. As far as I know, there's
> currently no way to capture more than one output stream into separate
> variables without involving rather laborious handling of temporary
> files. Your proposal would probably still involve that, but the shell
> would do the hard work for you which seems like an improvement to me.
> 
> BTW, 'reverse here-document' doesn't sound quite right. You're not
> specifying any document or string containing input, you're specifying a
> variable in which to store output. So, here-variable?
> 
> - M.
> 

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web