Path: csiph.com!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: Re: redirecting a file descriptor to an array variable? Possible? How? RFE? Date: Wed, 18 Nov 2015 11:53:40 -0800 Lines: 68 Approved: bug-bash@gnu.org Message-ID: References: <564532BD.60801@tlinx.org> <20151113131735.GE27325@eeg.ccf.org> <56488802.10800@tlinx.org> <20151116134157.GJ27325@eeg.ccf.org> <564CC08E.9060809@tlinx.org> <20151118184637.GI27325@eeg.ccf.org> 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 1447876432 24623 208.118.235.17 (18 Nov 2015 19:53:52 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Greg Wooledge To: bug-bash Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <20151118184637.GI27325@eeg.ccf.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 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:11908 Greg Wooledge wrote: > You should stop using irrelevant examples, and return to your core > question. I believe your initial goal was to run a command, and capture > the command's stdout in one variable, and the command's stderr in another > variable, without using any temp files. ---- Actually, wanted them already line split into 2 arrays. That's why I didn't care too much if the lines were separated by NUL's instead of NL's. > Come up with some syntax ---- The syntax isn't the hard part -- really, I think there are several formats that could be used that wouldn't conflict w/current uses. I'm more interested in some of the features...like the ability to separate input datums w/NUL's read by readAR/mapfl seems perfect for this type of thing. The opposite side -- printing things out with a nul or NUL-sep is missing -- but WOULDN'T be missing if bash's implementation followed the man page. I.e. If "$v" could really store '"\x00"\n', then another huge lump would "go away". > I would steer away from >&punc where "punc" is some third punctuation > characters. We already have >&word for FD duplication and closing, > where "word" can be an integer FD to duplicate, or - to mean close. --- Except that would be the wrong thing to do. You have: 1) optional 'fd' to work with -- that, currently has to be blank or evaluate to an integer; so (after quote removal) it has to start with [$0-9]. 2) "direction": into something (<); out of something (>); a not-so-useful way to open a file with RW access(<>) (but no way to seek, skip, truncate or use use mapfile/readarray because of the embedded nul problem; the "through" something (|). 3) then comes the 2nd operand which says "word", but where is 'word' defined. Is that any varname or funcname or alias name? Words normally don't start with "$" though varnames do. Words, also, don't normally start with '(' but a subprocess can -- e.g. process substitution). Since you are wanting to retain field '1' and field '2', it seems a specification for '3' indicating array usage would be a perfect fit for the language... Since '@' is already used as a subscript meaning all of an array -- using '@' before a 'word' would store multiple, separated, 'lines' as members in the array specified by 'word' & after the '@'. Something that parallels the syntax would be a better solution, I believe, than coming up with something that looked entirely unrelated, no?