Date: Mon, 10 Sep 2018 16:49:49 +0100
From: Geoff Clare <g...@opengroup.org>
Message-ID: <20180910154949.GA26031@lt2.masqnet>
| I looked at the text on netbsd.gw.com/cgi-bin/man-cgi?sh++NetBSD-current
| and I do not think it could easily be adapted for use in the standard.
OK
| The main problem is that it considers the '!' not to be part of the
| "pipeline" that has a "pipeline status".
Well, perhaps.... The name could be changed to something other
than "pipeline" status, To borrow wording from the grammar (though
it is a little unweildy) it could be "pipe_sequence status" instead of
pipeline status.
The point was more that extracing the status in two steps (which I suspect
is how it is always implemented) allows each of those speps to be
explained once, rather than the table, which requires each to be
explained twice, in different combinations.
| > I am not sure what the attitude is here to creating new special
parameters,
| We would need it to be implemented in at least one widely-used shell
| before we could consider standardising it.
Of course. More than one would be better (even necessary I think.)
My question, before doing a "less than 'widely' used" implementation was
as to whether adding a new special parameter is something that would
ever be considered acceptable at all.
And as an additional point, that arrays are not needed to expose the
status of the commands in a pipe_sequence, it can be made available
in an easily accessible manner that does not require addition of a
whole new element syntax, plus all the minor changes everywhere
else that would be needed to cope with it.
| Using the character '|' is problematic because it is an operator.
Yes, I can see that might be an issue - as I said I have not implemented
this, as I have not seen the demand for it.
But I guess I considered that $| could be treated in a way similar to $(
and treated a little specially by the tokeniser - but upon reflection while
easy to do, that does look to be a little crude (just as is the "io_token").
The actual name of a new special parameter is the least relevant question
here though, it could be $/ which has almost as much appeal as $| given its
relationship to $? (same keyboard key...) and that / is just | written
sloppily ... and if we finally drop ^ as any kind of operator at all, $^ would
keep that historic reference alive, or $+ as a list of (more than one usually)
statuses that are "added" ,,, there are lots of other less desirable
possibilities ... $% $, $. $= ....)
kre
ps: as a group operational question, is it, or would it be, reasonable to have
an "issue" that is opened, discussed and revised as needed, but then simply
kept unresolved (for perhaps quite a long time) for situations where something
that is new seems desirable, but is not ready to be standardised ... just so
there is somewhere where implementors can find specifications for potential
new features, so that when a need arises they can see how a solution has
already been proposed, rather than needing to go invent something new, and
possibly different, from what others are doing ?
