Date: Fri, 6 Mar 2020 07:21:29 +0000 From: Austin Group Bug Tracker <nore...@msnkbrown.net> Message-ID: <c25e264155c6243863d9e250caf10...@austingroupbugs.net>
| A NOTE has been added to this issue. | A few explanations related to ... Ugh. I hate the mantis web interface! That note escaped from me (twice) before I was finished with it, hence it was later edited (twice). Ignore the e-mail about the (this) note, what's there is incomplete nonsense instead look at what is on mantis now, alternatively, this is what that note ended up saying, after editing (just to finish content, there might still be typos). kre A few explanations related to Note: 0004794 A few of the changes are just intended to clarify what is stated now in the way I feel it should be stated to avoid potential problems, eg: where XCU 2.4 says: Words that are the concatenation of a name and a <colon> (':') are reserved; their use produces unspecified results. it doesn't say that this applies only where the word appears in a place where a reserverd word might be recognised, so for example, taken literally this would mean echo Usage: whatever (ignoring whatever effect my use of echo might have here) would have unspecified results, because Usage: is a word that is the concatenation of a name and a colon. That kind of thing should be fixed whatever else happens, and as making time back being an unspecified reserved word means changes all around that area (and ideally we need a method to introduce new reserved words, without stepping on the planned label namespace) this seemed like a good opportunity to fix this kind of wording. Apart from that the intent is to make unspecified all of the cases where time being a reserved word, and time being a utility are different, while leaving the simple case time cmd [arg...] as meaning the same as it does where the time utility is invoked, so that usage remains safe to use (but only in this very simplest of cases). That will make things like attempting to define time as a function non-conformant as reserved words cannot be redefined that way, while leaving it open for any implementation that treats time as a reserved word to largely do as it wants (within the confines of what reserved words can do). We can work on an entirely new method for timing shell operations (including utility invocations) later - for issue 9 or something...