[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: |
Wed, 17 Feb 2021 23:39:07 +0800 |
2021年2月17日(水) 21:56 Robert Elz <kre@munnari.oz.au>:
> | For example, this alone doesn't explain why
> |
> | $ if :; then echo A; fi if :; then echo A; fi
> |
> | (i.e., the combination "fi if") is a syntax error.
>
> That one is quite a different issue,
Yes, that's what I wanted to claim by the above example, that is, XCU
2.4 isn't the (most) essential point for the reason that `fi esac' or
`fi fi` is a valid construct. The above example is just a
counter-example against explaining `fi esac` by solely XCU 2.4. I used
`fi if' as an example because I did know that `fi if' isn't allowed by
the grammar, so I have referred to the grammar in the next paragraph
in my previous reply. Instead, as you have explained in your next
paragraph, the essential reason why `fi esac' can appear in a valid
command is that the grammatical structure allows the combination of
`fi esac' as a result of some embedded compound command in another.
> ps: many of these strange rules all originate in the original Bourne
> shell's recursive descent parser,
I was also thinking these apparent rules are strange before carefully
reading the BNF (in yacc style) specified in XCU 2.10, but now I
somehow feel these rules are understandable (but still not so natural
of course). I admit that it is confusing to most users, but at least,
I wouldn't say it's ``insane'' now.
> [...] and consequently, POSIX, which documents
> what actually exists, specifies it as well.
Thank you for the explanation of the historical backgrounds. That's
actually exactly what I guessed when I looked at the BNF.
Anyway, even if the POSIX specifies some inconsistent grammar, I feel
that cannot be the reason that Bash behaves in a way even more
inconsistent than what POSIX specifies.
--
Koichi
- Re: syntax error while parsing a case command within `$(...)', (continued)
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Oğuz, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Oğuz, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Oğuz, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Chris Elvidge, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/16
- Re: syntax error while parsing a case command within `$(...)', Robert Elz, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)',
Koichi Murase <=
- Re: syntax error while parsing a case command within `$(...)', Andreas Schwab, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Robert Elz, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Chet Ramey, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Robert Elz, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Koichi Murase, 2021/02/17
- Re: syntax error while parsing a case command within `$(...)', Chet Ramey, 2021/02/18
- Re: syntax error while parsing a case command within `$(...)', Oğuz, 2021/02/21
- Re: syntax error while parsing a case command within `$(...)', Chet Ramey, 2021/02/21
- Re: syntax error while parsing a case command within `$(...)', Oğuz, 2021/02/22