Re: inconsistent readonly error behavior

[Travis Everett]

I think I'm missing or misreading something. If I understood, the
assignment and expansion errors are both shell errors that should have the
same exit behavior?

But I see the assignment error ending the list and returning to the top
level, and the expansion exiting the script:

readonly sigh=1
if true; then
sigh=2
echo reached1
fi
echo reached2
if true; then
echo ${bad:?word}
echo reached3
fi
echo reached4

outputs:

./shell_error.sh: line 5: sigh: readonly variable
reached2
./shell_error.sh: line 8: bad: word

On Wed, Dec 23, 2020 at 9:09 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 12/22/20 12:21 PM, Travis Everett wrote:
> > I don't understand what distinction you're trying to make; any example
> you
> > can give?
> >
> > I added an extra near-copy of the script to the gist replacing the
> > assignment with unset
>
> `unset' is a different thing. It's a special builtin, so POSIX requires a
> non-interactive shell to exit when it fails. The question is whether or not
> attempting to unset a readonly variable counts as a failure; the standard
> says only "Read-only variables cannot be unset" and doesn't require it to
> be an error. Behavior varies.
>
> (
> >
> https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68#file-unset-sh-console
> ),
> > and corresponding output where you can see that it hits all of the lines
> > skipped in the assignment example. (The behavior in this example is in
> line
> > with what I see by replacing the assignment with other errors like a
> > missing command, or a ${parameter:?word} expansion.)
>
> A `missing command' is not a shell error. An expansion error requires the
> shell to exit under the same conditions as a variable assignment error, and
> the bash behavior in posix and default modes is the same.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>