Re: Directing into a variable doesn't work

[L A Walsh]

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.
---
   I think he's asking for the output to be able to go to some
type of bash data-type, in some way -- something I've asked for in
the past as well.  Details of implementation could be left to those
who know bash-syntax more. 
> 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.
>   
Only as much as not using using pipes vs. tmp files already impacts
execution -- something that has also been a RFE topic for this
list.  Opening a file on disk physical disk is expensive compared
to pipe in most circumstances -- especially on Windows derivatives
like Cygwin.

Performance of tmp file usage over pipes is so bad that I've never
seen large projects built without the "-pipe" arg being passed to
gcc.  Programs like vim provide for a user specification of memory
to be used (memmax memmaxtot) for files before spilling to a tmp.
> 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.
>   
---
   You wouldn't have tmp file confusion (though I think bash uses
uniq tmpfile names), if pipes were used.

   I see chet mentioned that someone else asked for this last month
I know I've asked for it in the past as well.  I suspect there's a
recurring request for this feature just that the implementation details
regarding nulls in the data are holding things up.  Even if the null
were encoded, bash tends to truncate strings with embedded nulls
upon assignment.  That makes any use of a POSIX compatible shell
a bit as archaic as POSIX in dealing with such -- especially now
that, at least, null terminated strings are becoming more common.

   Maybe a bash++ based on C++ that internally stores strings
with their length might someday deal with the problem, but I
wouldn't hold my breath.