Please ignore, superseded by subsequent discussion.
> -----Original Message-----
> From: Schwarz, Konrad (CT RDA IOT SES-DE) <konrad.schw...@siemens.com>
> Sent: Tuesday, April 21, 2020 10:18
> To: Robert Elz <k...@munnari.oz.au>
> Cc: austin-group-l@opengroup.org
> Subject: RE: aliases in command substitutions
>
> > -----Original Message-----
> > From: Robert Elz <k...@munnari.oz.au>
> > Sent: Monday, April 20, 2020 15:35
> > To: Schwarz, Konrad (CT RDA IOT SES-DE) <konrad.schw...@siemens.com>
> > Cc: austin-group-l@opengroup.org
> > Subject: Re: aliases in command substitutions
> >
> > Date: Mon, 20 Apr 2020 07:12:03 +0000
> > From: "Schwarz, Konrad" <mailto:konrad.schw...@siemens.com>
> > Message-ID: <mailto:38be7e5d52c74c9dac140f7de5105...@siemens.com>
> >
> > | Not sure if I understand your problem,
> >
> > I suspect probably not.
> >
> > | but I've always understood the
> > | case xxx in
> > | (pattern) ...;;
> > | esac
> > |
> > | (fully parenthesized pattern) syntax to have been invented precisely
> > | to allow case statements in $() subshell notation,
> >
> > First, $() is command substitution, not a subshell (not really
> > important) and if that was someone's intent, they did a particularly
> > bad job of implementing it, as what the standard says is (XCU 2.6.3)
> >
> > With the $(command) form, all characters following the open
> > parenthesis to the matching closing parenthesis constitute the
> > command. Any valid shell script can be used for command, except a
> > script consisting solely of redirections which produces unspecified
> > results.
> >
> > Note the "any valid shell script" (with that one exception) - a valid shell
> > script certainly includes a case statement where the optional
> '('
> > is omitted.
>
> Note the "matching closing parentheses", which means _lexical_ matching,
> i.e., counting the number of open and closing parentheses
> in the source text.
>
> >
> > My guess has always been that the '(' was invented as a sop to
> > parenthese balancing editors - to make it possible for those things to
> > assist with
> > balancing parentheses. But that's mere speculation, I wasn't around at
> > the time. A workaround for broken shells is another possibility.
>
> What makes more sense: that it was invented for interactive editing (but the
> line oriented structure of the shell makes this a non-
> issue -- it is visually clear where a case statement starts and ends, and
> also, at top level, so 99% of uses, the case statement is not
> enclosed in parentheses, so there is nothing for the editor to skip over) or
> to make it possible for the $() form of command
> substitution to include case statements without requiring full parsing of the
> contents of the $()?
>
> Note that the original form, in backticks, was purely lexical as well, but
> the rules were convoluted (ad hoc) and the Bourne shell was
> broken in regards to nested command substitution anyway? The $() notation
> was invented precisely to make it easy to use nested
> command substitutions and was defined in such a way as to allow for simple
> lexical scanning (count opening and closing parentheses)
> to determine its end.
>
> [snippng the rest of the message]
> I think you are on a completely wrong tangent: there is no need for subshell
> parsing to occur when looking for the end of command
> substation; this is purely lexical scanning.
>
