[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: syntax error while parsing a case command within `$(...)'
From: |
Lawrence Velázquez |
Subject: |
Re: syntax error while parsing a case command within `$(...)' |
Date: |
Wed, 17 Feb 2021 00:17:17 -0500 |
> On Feb 16, 2021, at 10:42 PM, Dale R. Worley <worley@alum.mit.edu> wrote:
>
>> Oğuz <oguzismailuysal@gmail.com> writes:
>>
>> `;;' is optional for the last case item.
>
> The manual page (for my version) says it's required. If, in some
> certain circumstances, it works without, that's nice.
It's also required by POSIX.
> But there's no commitment that it will work now, or in future
> releases.
The commitment is bash's claim to POSIX compliance. Outside of
command substitutions, the referenced construct currently works,
as POSIX requires. I expect this is by design. If it ceases to be
recognized in the future, then bash will have intentionally become
less compliant with POSIX, for no good reason.
>> `case x in esac' (without the linebreak) works fine outside the
>> command substitution.
>
> The manual page (for my version) says that "esac" will be recognized
> in positions where a simple command may appear.
The 5.1 man page doesn't say that, or I can't find it, but it doesn't
matter because a simple command can't go immediately after that "in".
> If, in some other circumstances, it works, that's nice.
Recognition of "case x in esac" is also required by POSIX.
> But there's no commitment that it will work now, or in future
> releases.
See above.
> Now, if you want to advocate that it *should* always work, go ahead.
> But that's a feature request, not a bug report.
TO: Chet
SUBJECT: Feature request
Please do not make bash less POSIX-compliant for no good reason!
thx
vq
- Re: syntax error while parsing a case command within `$(...)', (continued)
Re: syntax error while parsing a case command within `$(...)', Dale R. Worley, 2021/02/14
Re: syntax error while parsing a case command within `$(...)', Eli Schwartz, 2021/02/14
Re: syntax error while parsing a case command within `$(...)', Chet Ramey, 2021/02/15