Robert Elz <k...@munnari.oz.au> wrote, on 24 Feb 2020: > > But we really do not need to defer bug 267 until all that is worked out, > this will take a long time, as not only do we need a proposal, we need > implementation experience, and then application use to verify it is > suitable, and shouldn't be improved before it is finalised, and then more > widespread implementation -- if we happen, just by chance of course, to make > the new reserved word, at least in its basic form - some extensions might > be nice - mean just the same as what "time" does now in those shells which > implement it as a reserved word (modulo what stuff in TIMEFORMAT means, which > looks like another giant mess, so we should not usurp that one) then I suspect > getting implementations in those shells might not be all that difficult.
You are looking further ahead that we need to at this point. 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. If your and Chet's new proposal looks promising, we will likely abandon the current direction 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. [...] > We can make sure that implementations that have implemented time as a > reserved word aren't contrary to the standard though, since it seems that > was the intent. > > At the minute I see just one real issue, are there others? > > > What that leaves, to me, is the issue with functions and aliases. When > time is a reserved word, it cannot be defined as an alias (who cares) or > as a function (a slightly bigger issue). Since there is no reasonable > way out of this, I believe the only thing to do is to prohibit its use > for those purposes (an automatic side effect of making it a reserved > reserved word), as scripts that attempt it simply won't work with > many shells (and consequently I doubt there are very many such usages). You missed the issue that was the reason bug 267 was raised - redirection of the timing information. 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. Bash gives timing output when the command is stopped (and none when it completes). Ksh88 on HP-UX and ksh93 on Linux do the same. With ksh88 on Solaris, timing a command prevents it from being stopped with Ctrl-Z. Ksh93 on Solaris produces no timing information at all. (All tested with the relevant shell as the login shell and using "time /bin/sleep 10" then hitting Ctrl-Z and - if the command was stopped - using fg to continue it.) If we end up deciding to add your and Chet's new feature, 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". -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
