2017-06-15 13:56:16 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > One more major issue identified in this thread is that in TC2, > > the "until" in > > > > < file until... > > > > or: > > > > foo=bar until... > > > > is now required to be recognised as the "until" keyword, and > > it's not in most shells (an exception is zsh for the first > > case). > > Could you explain since when this is required?
To clarify, it's now required *by mistake* (as in an unintential (I beleive) consequence of a change made to the spec). As discussed earlier it's because of the change in 7b in between: http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/V3_chap02.html#tag_18_10_02 and http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/V3_chap02.html#tag_18_10_02 From: TC1> b. [Not the first word] TC1> TC1> If the TOKEN contains the <equals-sign> character: TC1> TC1> * If it begins with '=', the token WORD shall be TC1> returned. TC1> TC1> * If all the characters preceding '=' form a valid name TC1> (see XBD Name), the token ASSIGNMENT_WORD shall be TC1> returned. (Quoted characters cannot participate in TC1> forming a valid name.) TC1> TC1> * Otherwise, it is unspecified whether it is TC1> ASSIGNMENT_WORD or WORD that is returned. To: TC2> b. [Not the first word] TC2> TC2> If the TOKEN contains an unquoted (as determined while TC2> applying rule 4 from Token Recognition) <equals-sign> TC2> character that is not part of an embedded parameter TC2> expansion, command substitution, or arithmetic expansion TC2> construct (as determined while applying rule 5 from Token TC2> Recognition): TC2> TC2> * If the TOKEN begins with '=', then rule 1 shall be TC2> applied. TC2> TC2> * If all the characters in the TOKEN preceding the TC2> first such <equals-sign> form a valid name (see XBD TC2> Name), the token ASSIGNMENT_WORD shall be returned. TC2> TC2> * Otherwise, it is unspecified whether rule 1 is TC2> applied or ASSIGNMENT_WORD is returned. TC2> TC2> Otherwise, rule 1 shall be applied. With the new wording (the last line above), that "until" doesn't contain an unquoted "=" which means rule 1 applies which means it's to be treated as the "until" keyword (and 7a is now obsolete). I was wrong about POSIX previously requiring it to be treated as "WORD". Scratch that. The text in TC1 was perfectly fine in that regard. [...] > It is however a bug that the Bourne Shell and it's derivates like ksh and bosh > do not allow a I/O redirection before such a command since it is permitted > after a command already. Well, it would be a "bug" if it was documented that such redirections were allowed. > > < file time cmd > > < file ! cmd > > a=1 ! cmd # that one unclear whether the a=1 would apply to all > > # the commands in the pipeline though > > < file { ...; } > > > > as an extension. > > < file time cmd already works in Bourne Shell and it's children But in those where "time" is a keyword, it's no longer treated as a keyword, so the "time" *command* (if available) is invoked instead. In those: < file time foo | bar times "foo" only, while: time foo < file | bar times foo | bar. > < file ! cmd The fact that this does not work must be seen > as a bug since both constructs are parsed the same way. The difference is that here, there's no usually no "!" *command* like there is a "time" command. [...] > > $ zsh -c '< file f() { echo x; }; typeset -f' > > f () { > > echo x > > } < file > > This looks like a bug: the command that is redirected is the function > definition, so "< file" does not belong here. Since it's not documented either way, it's not a bug. Given that zsh supports anonymous functions, like in: < file () { echo "$@"; cat - "$@"; } ./*.txt Doing it the way it does now makes more sense. It's never useful to redirect a function definition since that doesn't do any I/O. > > $ ksh -c 'f() < file (echo x); typeset -f' > > ksh: syntax error at line 1: `<' unexpected > > This is illegal syntax, a corrected variant of what you seem to intend is > e.g.: If "< file (subshell)" works, I don't see why "f() < file (subshell)" should be illegal. > > $ mksh -c 'f() < file (echo x); typeset -f' > > f() ( echo x ) <file > > $ zsh -c 'f() < file (echo x); typeset -f' > > f () { > > ( > > echo x > > ) < file > > } > > As mentioned: if this works, the related shell has a parser bug. Again, I don't agree. -- Stephane
