bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: syntax error while parsing a case command within `$(...)'


From: Koichi Murase
Subject: Re: syntax error while parsing a case command within `$(...)'
Date: Tue, 16 Feb 2021 20:15:43 +0800

2021年2月16日(火) 19:24 Oğuz <oguzismailuysal@gmail.com>:
> XRAT Shell Grammar (  
> https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_10
>  ) explains that giving almost the same examples as we posted in this thread.

Thank you, interesting! So, if I understand correctly, the following
construct which Bash allows is finally disallowed by POSIX?

$ if (false) then (echo x) else (echo y) fi

To summarize, the following cases are required by the POSIX standard
to be correctly parsed?

$ bash -c ': $(case x in esac)'
$ bash -c ': $(case x in (x) if :; then echo a; fi esac)'
$ bash -c ': $(case x in (x) a() { echo a; } esac)'
$ bash -c ': $(case x in (x) { echo a; } esac)'
$ bash -c ': $(case x in (x) while false; do echo a; done esac)'
$ bash -c ': $(case x in (x) case y in (y) echo a;; esac esac)'

and this case

$ bash -c ': $(case x in (x) (echo a) esac)'

could be a Bash extension. But actually, it totally depends on what is
"the matching closing parenthesis" in the description of the command
substitution by the POSIX:

XCU 2.6.3 Command Substitution
> With the $(command) form, all characters following the open
> parenthesis to the matching closing parenthesis constitute the
> command.

I guess the rationale of the current Bash behavior is that "the
matching closing parenthesis" in the context of the command
substitution is actually not strictly defined in the standard.

--
Koichi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]