Path: csiph.com!goblin2!goblin-spool!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: L A Walsh Newsgroups: gnu.bash.bug Subject: Re: Directing into a variable doesn't work Date: Mon, 25 Jun 2018 15:11:14 -0700 Lines: 59 Approved: bug-bash@gnu.org Message-ID: References: <634e501a-5db1-d9ae-ae0b-bb3b414a2def@passchier.net> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1529964692 11902 208.118.235.17 (25 Jun 2018 22:11:32 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Martijn Dekker Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14278 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.