Date: Mon, 24 Feb 2020 15:09:54 +0000
From: Geoff Clare <g...@opengroup.org>
Message-ID: <20200224150954.GA3455@lt2.masqnet>
| You are looking further ahead that we need to at this point.
I knew that, as you would have seen lower down, I only added that point
as you seemed as if you were waiting a month for a proposal from me (and
perhape Chet) for a replacement ... the implication being that perhape if
nothing reasonable was forthcoming by then, then something along the lines
of current proposed wording on 267 (cleaned up as needed perhaps) might/would
go ahead. But a month wouldn't be long enough to wait for that.
| For now, the teleconference participants just need enough info to make
| a decision(probably on March 23) of which direction to take for bug 267.
I would have thought the directions is already clear (and you summarise
it below) - what is needed now for that is the details. A month seems
like a reasonable time to clean that up.
| If your and Chet's new proposal looks promising, we will likely
| abandon the current direction
Now I am back to thinking that you are expecting something new within
a month, and that's unreasonable. If it is to be good it needs to be
tested, and that means getting all kinds of different people with
different needs to use it, and give feedback, and then to react to that
by changing the p[roposal if needed. And all that is after design and
implementation.
But if you just want a rough idea, it will (I suspect) look rather like
the reserved word time does in shells that support it now, just with a
different reserved word (not yet selected) and most likely cleaned up
some (no longer needing to try and coexist with the time utility).
| and start thinking about what changes
| would be needed to the existing text in order to lay the groundwork
| for adding the new feature later on.
The only think I can think of there would be to reserve the name asao
(if needed). If we want to go that route, and of the names suggested
recently, Mark's suggested "statz" is the one that appeals to me most.
But we can also just agree to use a name ending in ':' in which case it
is already reserved, and nothing really needs to be done (you could add
words saying "names ending in : are reserved, unless defined by this
standard. Currently there are none, but new reserved words might be
added in future editions" somwehere - in some rationale, or future
directions, I guess). That might be worth doing anyway, just to allow
a mechanism to add unrelated new reserved words if it ever seems
advisable (I cannot think of anything right now, but who knows).
That is unless there is some other good reason that names ending in ':'
must be kept reserved and never used for anything. Anyone?
| You missed the issue that was the reason bug 267 was raised - redirection
| of the timing information.
You're right, I did. So we need to make that unspecified as well.
Making stuff unspecified is always something of a cop-out ... but it does
tend to reflect reality.
| Another issue I discovered recently is that shells with time as a
| reserved word behave strangely when the command being timed is stopped
| by a signal.
Ugh... Hadn't even considered that possibility. There is a lot of
unliness around process that stop, and very little consistency in what
happens in many of them (processes that stop in loops, ..., are another
source of continuous problems ... not relevant to this issue.)
| If we end up deciding to add your and Chet's new feature,
I think that regardless of that, this ...
| then I think what we should do for "time" is add it as an unspecified
| reserved word (alongside select and [[) and advise that conforming
| applications should avoid using the reserved word and instead make
| sure they use the time utility, e.g. by quoting the word "time",
| using "command time ...", or having a word expansion result in the
| word "time".
is roughly what we must do. There really is no need to wait a month
to make that decision. I'd prefer it, for the sake of existing
conforming scripts (or some/most of them anyway) if we can find a way to
make some uses of
time simple-command
(no pipelines or redirectios involved) still acceptable (defined) when
it is a simple enough case that it works everywhere, just to avoid some
future shell deciding to go in some other direction completely, and relying
upon the "applications are not allowed to use unquoted 'time'" wording).
But if we cannot find suitable wording to make that happen, then so be it.
But that is what I would prefer to spend time over the next month
woirking on, rather than trying to come up with a half baked (which is
all it could be) proposal for a replacement within that period.
However contuing along the lines of the current 267 resolution proposal
is totally the wrong thing to do, we cannot simply reverse the considered
decision of the earlier deliberations (which most likely conisdered much
more than we have so far) and turn time into a reserved word, rendering
non-conformant (perhaps just in one more way) shells which have perfectly
complied with the standard in this area until now.
kre
