Date: Tue, 25 Feb 2020 17:47:23 +0000 (UTC)
From: shwaresyst <shwares...@aol.com>
Message-ID: <1701159045.321204.1582652843...@mail.yahoo.com>
| The thing is, various shells have implemented time as keyword, so this bug
| is trying to get the standard to reflect actual practice that ignored that
| Rationale.
The first part of that I understand, and what's more, that was predicted, even
known, at the time, as the implementations (at least one) already existed.
Further it was intended to be permitted - that much is clear, they just
didn't realise all they needed to make unspecified in order for that to work.
| The debate is more some things allowed to utilities aren't allowed
| for keywords, and vice versa, so there are advantages to both.
Then that's a pretty silly debate, as absolutely anything can be allowed
for a keyword - part of defining a keyword (which is a grammar token) is
defining the grammar rules that use it, and those can be just about anything
that's desired, in any form that's desired. It just needs to be consistent
(ie: not cause a conflict, I don't mean be similar to) with the rest of the
grammar.
More likely the real problem here is how to define the grammar for time as
a reserved word to make it match the actual implementations correctly.
That I haven't considered, as I don't think it should even be invented.
We should not be inventing new reserved words that are not in the standard.
An unspecified reserved word (one which might be reserved, or might not be)
is as far as is reasonable to go, and even that is a huge push at the limits.
| As another option, if an approach is to be invented, the utility could
| change from being a regular utility to a special built-in,
That doesn't help - the only differences between them are some execution
time weirdnesses (error consequences, effects of var assigns, etc).
Further, that must be the case, as the relevant part of the script will have
been parsed before we even know what kind of command it is (whether built in
or not, and if built in, whether special or not). It is way too late to
make syntax decisions, of any kind, by then.
| This method adds capability not available to keywords
| such as redirections
keywords can have redirections, almost all of them do, or at least the
structures they define do (all of for/while/until/case/()/{} can be redirected
(subshells aren't implemented with keywords, but with operators, but the
effect is the same for that particular operator pair in this regard).
| and multiple utilities,
Sorry, don't understand what that means.
| pipelined or not
Where a program structure introduced by a keyword fits in the grammar
is entirely up to the grammar to determine - and provided it isn't made
ambiguous by so doing, it can have different structures in different
circumstances if desired.
But a utility can only ever be an element in a pipeline, we have no idea
what utility is to be invoked until after the pipeline structure has been
parsed.
| and requires no grammar changes.
That is certainly correct.
I suspect a large part of the problem might be because of the limits of
the current implemented time reserved word. That's horrid, and most likely
only in the form it is because it was copying csh, and for some reason,
apparently a need was felt to make the syntax compatible with csh's syntax,
which was a patently absurd decision. Had time been something like
time list
with word ...
emit
which would have been sh type syntax (that can be rearranged as desired,
the word... specify the options, format, ... "with" can be "using") or
perhape
time word ...
do
list
emit (or done)
to avoid adding too many new reserved words. and use would be
something like
time format '%E elapsed %.3U/%.3S user/sys\n' summary; do
for f in *.c; do grep time_me "$f"; done >&3 3>&-
emit 3>&1 >/tmp/time_log
but this is all just fantasy.
| A time format could be an argument to the -b switch, getting rid
| of any dependence on a shell variable being set or not too.
Yes, for any new time like thing that is added, this would clearly be
a good idea, but the csh way didn't do that, so ksh's time didn't either.
Dumb.
| It has the advantages of both other approaches, in other words, and more.
No form of utility has any advantages over the time utility we have now.
We can easily add more options to that if they're implemented somewhere,
and any shell can make it a built-in (being special changes nothing that
matters) - but that is not what is needed as an additional feature, and
not what the time reserved word provides.
kre
