> -----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.


Reply via email to