Date: Wed, 26 Feb 2020 03:10:31 +0000 (UTC)
From: shwaresyst <shwares...@aol.com>
Message-ID: <1721701622.609847.1582686631...@mail.yahoo.com>
| No keyword, on its own, presently in the standard is required to produce ou=
| tput that may be redirected.
That is certainly correct. That doesn't mean that a new keyword couldn't
produce output, which is what time does, and if it did, its output would
logically get redirected along with that of the commands it runs (which would
be then subjected to their own more specific redirections, as the fantasy
examples I gave showed). An alternative to that would be to have an
"output" word in such a design (since we only need to redirect output from
time, it has no input) or to allow its redirections to occur in the words
section - but this version then precludes use of its output into a pipe,
unless we also added a "pipeout" word - and that's going to absurd lengths.
The problem the current "time" reserved word has in this area is that its
syntax is (approximately)
time command
and command can have redirections anywhere, and contain just about anything,
so there is nowhere except possibly before the "time" word where redirections
could be placed which would apply to the output from time itself - and before
a reserved word is the one place that redirections cannot go, so that is out
as well. This means the only way left is to embed the time command in a
group, and redirect the group instead, which is simply different (and more
limited) syntax than the fantasy examples I gave.
| What redirections are permitted apply to utilities used with those
| keywords, not the keywords themselves, and this is where the conflict
| appears - does a stderr redirect with time as a keyword apply only to
| the output of time, which is desired but not implemented;
I don't know who would desire that, but it wouldn't be me. That would be
a truly horrible result.
| only whatever command(s) are being processed, as is currently implemented;
| or both as with the utility.
One of those is what it has to be, and the former is more flexible, if ugly.
But once again, I believe you're wasting time even considering any of this.
[Incidentally, in my previous message, where I wrote ...
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.
the final word was meant to be "considered" - I guess my brain was already
planning the next paragraph, which was using "invent" and my fingers got
confused...]
When this was originally discussued, I assume the standards writers of the
time (no pun...) looked at "time", the reserved word, saw how badly designed
it was, along with the conflicts with "time". the utility, and simply could
not bring themselves to inflict that nonsense on anyone. They should be
applauded for that. We should not be going anywhere near changing that,
all we need to do is to make the existing implementations of the time
reserved word no longer be non-conformant with the standard (which is
what they clearly desired to achieve ... we should simply finish that job).
That's it. The only hard part of this (aside from writing the correct
standards speak and formatting it properly, which I find mind blowing)
is to make sure we identify all the places where there are currently
problems, so we can fix them - which means - make it unspecified.
So, please, everyone, cease all efforts on trying to find ways to specify
the time reserved word, and instead use your considerable talents in various
areas to look for any other obscure cases where using time as a reserved word
currently violates the standard in any way.
| What I proposed could be grafted onto existing utility implementations,
| perhaps, but making it robust is much harder then, that I see, as you
| have to guard against date being used to modify the clock somehow,
I have absolutely no idea what you're thinking of here, but the shell is
also just a utility, and has no special privs wrt clock changes than any
other utility - anything the shell can do anything else can do as well.
But once again, it is simply *impossible* to get anything like the time
reserved word implemented as a utility, even a "must be built in" kind of
utility. Just stop dreaming about that, it cannot be achieved, or at
least not unless we totally redefine what it means to be a utility in the
shell.
The closest it is possible to come would be to make time like eval,
(as mentioned in a much earlier message of mine) which is given a string
to parse and execute (and in the case of time, also provide timing output).
That would be a must-be-builtin utility (as eval is) and could work ...
but then adds all of the quoting issues that arise with eval to uses of time.
eval's purpose is largely to deal with various different kinds of quoting
issues - so for that the difficulties are tolerable, for time, I am not
sure that the users would be quite so forgiving.
| As to getting it invented, roughly 80% of the bash implementation for
| posix mode can be reused, I estimate,
Yes, well, for inventing a new version of time, with a new keyword, and
proper syntax, that was largely the idea - it is always better to start
with something more or less working, and enhance it, than at ground zero.
| and changing from keyword to built-in as a new wrapper for that is
| straightforward, it appears.
No, not straightforward. Impossible. I have no idea if you've ever
actually been involved (deeply, not some superficial change here or there)
with a shell implementation, but the difference between how keywords work,
and are implemented, and how utilities (including builtins) work and are
implemented is so vast, that it is barely possible to conmtemplate them
as even the same species ... which is because they aren't. What you're
asking is to take something which is done by an elephant (say pull down
a tree in a couple of minutes), and graft it as a capability into a worm.
The difference is just that great.
| The backend for the new switches, as new code, is not as straightforward
That part of it is trivial, once the syntax is known and correct, and
the parsing is done, actually implementing this is child's play.
We know how to do that (there are some edge cases around timing builtins
and functions, etc., that need care, but all of that is manageable)
- the hard part is desiging the correct user interface so the right level
(not too little, and not too much) of flexibility and control is available.
kre
