It is certainly a good thing that this has been reopened, as what
was proposed to be inserted is, frankly, nonsense.
It is not that I have anything against a time reserved word, though
being a reserved word rather than a builtin, or special builtin does
make it impossible to redirect (as has been noted) and also raises
questions as to what exactly happens on error (like an invalid format
string in TIMEFORMAT, or a command not found, etc) - does it act like
a special builtin with an error, or a regular command. Those kinds
of things could (and should) be fixed .. but that's more difficult
for a reserved word which doesn't have the utility page with its
standard format in which all of this has a natural place.
But the proposed grammar (and also one of the proposed replacements)
is broken, the "linebreak" non-terminal cannot be used the way it was
(and apparently still is) being proposed - doing so would make the
grammar ambiguous. That might be OK if you're feeding it to yacc,
where the shift/reduce conflict resolution rules will settle on one
interpretation, but is definitely inappropriate to use in a standard.
"linebreak" can only ever be used in a rule when there is at least
one more required syntactic element to follow - that isn't to say
that it cannot be the last element of a rule - but only when that
rule is embedded in another (or which is itself embedded in another)
in which something else (not a command termination) is required.
Or in other words, it is only ever used in places where the current
command cannot possibly end at the current place, and it is desired
to allow a newline to be inserted, such as after most reserved words,
after && || | (and similar, including '(' itself).
So
pipeline : pipe_sequence
| Bang linebreak
| (other stuff)
cannot be correct, as
linebreak : newline_list
| /* empty */
and_or : pipeline
| (other stuff)
list : and_or
| (other stuff)
complete_command : list separator_op
| list
complete_commands: complete_commands newline_list complete_command
| complete_command
program : linebreak complete_commands linebreak
| linebreak
If we were to have simply
!\n
as input (where the \n means a single newline character) then it is
ambiguous whether the newline matches the linebreak that is in "pipeline"
or the one in "program" and while that might seem insignificant, it isn't
for a grammar (and in more complex cases may make a real difference).
This problem is still in Mark's proposed replacement grammar, but isn't
in Stephane's (which is much better).
The original was much worse than this, I don't even want to contemplate
what
pipeline : pipe_sequence
| Bang linebreak
| Bang pipeline
| (even more)
is useful for, or why anyone could conceivably want that.
But since there are proposed replacements without that nonsense, I assume
that you're aware of just how absurd this all is, and so I can stop this
part here.
But the above raises another issue, this bug report is supposed to be
about the "time" reserved word (keyword) - why would any solution to
that be making any changes at all to the way that the ! reserved word
works? Surely that would need to be done in a bug about either ! itself,
or a more general pipeline syntax bug report. Dealing with "time" as a
reserved word is complex enough without trying to slip in modifications
to "!" at the same time (and doing a half baked job of it), for now can
I assume that the proposed changes to the way ! is defined to work will
be dropped from this issue ... if there is some real desire for this
change make it be a new issue (and then I will say why I think it is
a very poor idea there, rather than here).
(The same is true of the changes that seem to make minor unrelated
changes to the grammar, to fix minor issues that were noticed - strictly
they should be separate issues (or at least one) ... it is hard enough
to search for stuff in mantis to see what is in the queue to be changed
already, but it becomes impossible when changes are buried within other
issues that are unrelated ... but as these look to be trivial, and not
controversial at all, unless I missed something, never mind).
Now to the actual subject matter ... first, and comparatively minor,
is it really desirable to make a reserved word ("time") (and I mean
when it is a reserved word, but I'll come to that below) into also
being a command? This would be a first for the shell I believe, until
this, reserved words are only ever syntax, never commands. Even some
of what is often considered syntax is actually implemented as commands.
Have all of the ramifications of this been considered? Note that this
relates to the use of "time" as a command, not to its use as a prefix for
a pipeline (where it is just syntax). I'd suggest just avoiding the
isssue, and drop the command form (a pipeline that is exactly "time"
with nothing else) -- all that it generates is a poor man's "times" command
with the only extra being the ability for users to control the output
format, better to add that ability to "times" than pervert the structure
of the shell. (Note that implementations are always free to extend the
language, and if a time command is in some of them, that's fine .. it
just shouldn't be in POSIX).
In case it is not clear, what all the above means is that I support
Oif anything) Stephane's proposed grammar revision, and none of the others.
But what is worst about all of this is...
"however, the word \fBtime\fP shall not be
recognized as a reserved word if the first
character of the next token is '-' (<hyphen-minus>)."
Huh?
This is another first... we have the case of IO_NUMBER but that is
distinguished from a word by the very next character (the character
that ended that token by not being included in it) - here we have to
skip forward until we have started recognising a new token before we
know whether we have a reserved word or a regular word. I'm not sure
how the ash shell type parser would handle that, though I'd assume it
is possible (all kinds of things are possible with this kind of parser)
but for a shell written using a formal grammar? The tokeniser would
need to be truly evil - I'd hate to imagine writing this using standard
yacc and lex.
But worse ... we have just seen the resolution of bug 252 - which made
(very slightly) non-backwards-compatible changes to the . and exec
commands, solely for the purpose of allowing them to work with utility
names that begin with a '-'.
Then, almost the next thing that happens, is that we're proposing
standardising a new feature in such a way that it cannot possibly work
with utilities with names that start with '-' (not even using "--").
What kind of message does that send?
Either "time" is to be a reseved word or it is not. That should be
governed by exactly the same rules as apply to all other reserved words.
No special hacks.
If this doesn't suit the existing implementations, they should find a
solution which doesn't require such an ugly hack, and the request
standardisation of that.
Allowing for the odd possibility that there is still some desire to
add this to the standard, I support limiting what is required as format
characters for TIMEFORMAT to the bare minimun needed (and yes, with %E
not %R) - but I'd also suggest in the application notes, or somewhere,
giving a list of the common extensions, so that we don't get a repeat,
at least as much as it can be avoided, of the ulimit mess, where it
seems that all shells support much more than POSIX requires, and mostly
support more or less the same set of limits (which of course mostly
depends upon what the underlying system supports), but don't have a lot of
common ground about which option letter operates upon which limit.
kre
All of this because of the ancient ksh desire to do everything that csh
could do, no matter how inappropriate it was to sh.
