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


Groups > gnu.bash.bug > #11908

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Path csiph.com!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail
From Linda Walsh <bash@tlinx.org>
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 <mailman.178.1447876431.31583.bug-bash@gnu.org> (permalink)
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 <wooledg@eeg.ccf.org>
To bug-bash <bug-bash@gnu.org>
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 <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <http://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref csiph.com gnu.bash.bug:11908

Show key headers only | View raw



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?





Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: redirecting a file descriptor to an array variable? Possible? How? RFE? Linda Walsh <bash@tlinx.org> - 2015-11-18 11:53 -0800

csiph-web