Re: Bad substitution breaks conditional statement
On 10/13/20 11:43 PM, Martin Schulte wrote:
> Consider the following script:
>
> #!/bin/bash
>
> echo "${x;:-}" ; echo "Not executed"
> echo "Executed"
>
> echo "${x:-}" ;; echo "Not executed"
> echo "Not executed"
> <<<
>
> It just a source of problems that the two syntactical errors (both caused by
> an extra semicolon) lead to different behaviour.
They are not both syntax errors. The first is a word expanion error. The
second is a syntax error because `;;' is an operator and it's not valid in
that context.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bad substitution breaks conditional statement
On 10/13/20 4:42 PM, Martin Schulte wrote: > Hi Chet, hi all! > >> In general, variable expansion errors cause posix-mode shells to exit and >> bash default mode shells to abort execution of the current command and >> return to the top level, whether that is the command line or the next >> command in the script. This aborts lists and other compound commands. >> Bash has always behaved this way. >> >> However, invalid parameter transformation operators are not considered >> fatal errors, even in posix mode. Maybe they should be. > > Yes, please :-) There are a couple of ways to go. The obvious one is to make it a fatal error when non-interactive and non-fatal in interactive shells. The posix mode setting should not matter because this is not a posix expansion. > > Or no error at all. No, that doesn't seem useful. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bad substitution breaks conditional statement
On Okt 14 2020, Martin Schulte wrote:
> Consider the following script:
>
> #!/bin/bash
>
> echo "${x;:-}" ; echo "Not executed"
> echo "Executed"
>
> echo "${x:-}" ;; echo "Not executed"
> echo "Not executed"
> <<<
>
> It just a source of problems that the two syntactical errors (both caused by
> an extra semicolon) lead to different behaviour.
The difference being that the first error occurs during execution, while
the latter occurs during parsing. The latter is also caught by bash -n.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Bad substitution breaks conditional statement
Hello Lawrence, hello *!
> >> However, invalid parameter transformation operators are not considered
> >> fatal errors, even in posix mode. Maybe they should be.
> >
> > Yes, please :-)
> >
> > Or no error at all.
>
> Why should invalid parameter transformation operators be treated
> differently from other invalid parameter expansions?
For sure all syntactical errors on parameter expansions should be handled in
the same way - I suggest they should be considered as fatal errors.
Consider the following script:
>>>
#!/bin/bash
echo "${x;:-}" ; echo "Not executed"
echo "Executed"
echo "${x:-}" ;; echo "Not executed"
echo "Not executed"
<<<
It just a source of problems that the two syntactical errors (both caused by an
extra semicolon) lead to different behaviour.
Martin
Re: Bad substitution breaks conditional statement
> On Oct 13, 2020, at 4:42 PM, Martin Schulte wrote: > > Hi Chet, hi all! > >> In general, variable expansion errors cause posix-mode shells to exit and >> bash default mode shells to abort execution of the current command and >> return to the top level, whether that is the command line or the next >> command in the script. This aborts lists and other compound commands. >> Bash has always behaved this way. >> >> However, invalid parameter transformation operators are not considered >> fatal errors, even in posix mode. Maybe they should be. > > Yes, please :-) > > Or no error at all. Why should invalid parameter transformation operators be treated differently from other invalid parameter expansions? vq
Re: Bad substitution breaks conditional statement
Hi Chet, hi all! > In general, variable expansion errors cause posix-mode shells to exit and > bash default mode shells to abort execution of the current command and > return to the top level, whether that is the command line or the next > command in the script. This aborts lists and other compound commands. > Bash has always behaved this way. > > However, invalid parameter transformation operators are not considered > fatal errors, even in posix mode. Maybe they should be. Yes, please :-) Or no error at all. Best regards Martin
Re: Bad substitution breaks conditional statement
On 10/12/20 1:23 AM, Martin Schulte wrote: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. > -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wno-parentheses -Wno-format-sec$ > uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) > x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > > It looks as if a bad substitution detected inside a case of if continues the > script flow immediately after the conditional statement skipping the > remaining statements inside the conditional. Please take a look into section > "Repeat-By:". In general, variable expansion errors cause posix-mode shells to exit and bash default mode shells to abort execution of the current command and return to the top level, whether that is the command line or the next command in the script. This aborts lists and other compound commands. Bash has always behaved this way. However, invalid parameter transformation operators are not considered fatal errors, even in posix mode. Maybe they should be. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bad substitution breaks conditional statement
On 12/10/2020 06:23 am, Martin Schulte wrote:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-sec$
uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
It looks as if a bad substitution detected inside a case of if continues the script flow
immediately after the conditional statement skipping the remaining statements inside the
conditional. Please take a look into section "Repeat-By:".
I detected this when running a script containing "${OPTARG@Q}" with a bash
4.1.5 where @Q is not yet supported - the script continued to run in a bad manner so this
bug might cause real troubles...
Repeat-By:
schulte@t1:~$ cat bad_substitutions_breaks_conditional
#!/bin/bash
x=y
case $x in
y)
echo "x has value ${x@q} - stop now!"
exit 1;;
esac
echo "running"
if [[ $x == y ]]; then
echo "x has value ${x@q} - stop now!"
exit 1
fi
echo "still running"
echo "x has value ${x@q} - stop now!"
exit 1
echo "and running"
schulte@t1:~$ ./bad_substitutions_breaks_conditional
./bad_substitutions_breaks_conditional: line 6: x has value ${x@q} - stop now!:
bad substitution
running
./bad_substitutions_breaks_conditional: line 11: x has value ${x@q} - stop
now!: bad substitution
still running
./bad_substitutions_breaks_conditional: line 15: x has value ${x@q} - stop
now!: bad substitution
Surely if you're using a construct that only exists in version X, it's
up to you to check if version X-1 is being used and throw an error
there. Isn't that what $BASH_VERSION / $BASH_VERSINFO is for?
--
Chris Elvidge
England
Re: Bad substitution breaks conditional statement
> On Oct 12, 2020, at 1:23 AM, Martin Schulte wrote:
>
> It looks as if a bad substitution detected inside a case of if continues the
> script flow immediately after the conditional statement skipping the
> remaining statements inside the conditional. Please take a look into section
> "Repeat-By:".
It does not really have to do with "conditionals" per se. You can
observe similar behavior with standalone lists.
% bash --version | head -n 1
GNU bash, version 5.0.17(1)-release (x86_64-apple-darwin18.7.0)
% cat /tmp/pe-test
: "${x!y}"
echo foo
{
: "${x!y}"
echo no bar
}
echo bar
: "${x!y}"; echo no baz
echo baz
% bash /tmp/pe-test
/tmp/pe-test: line 1: ${x!y}: bad substitution
foo
/tmp/pe-test: line 5: ${x!y}: bad substitution
bar
/tmp/pe-test: line 8: ${x!y}: bad substitution
baz
--
vq
Bad substitution breaks conditional statement
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-sec$
uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
It looks as if a bad substitution detected inside a case of if continues the
script flow immediately after the conditional statement skipping the remaining
statements inside the conditional. Please take a look into section "Repeat-By:".
I detected this when running a script containing "${OPTARG@Q}" with a bash
4.1.5 where @Q is not yet supported - the script continued to run in a bad
manner so this bug might cause real troubles...
Repeat-By:
schulte@t1:~$ cat bad_substitutions_breaks_conditional
#!/bin/bash
x=y
case $x in
y)
echo "x has value ${x@q} - stop now!"
exit 1;;
esac
echo "running"
if [[ $x == y ]]; then
echo "x has value ${x@q} - stop now!"
exit 1
fi
echo "still running"
echo "x has value ${x@q} - stop now!"
exit 1
echo "and running"
schulte@t1:~$ ./bad_substitutions_breaks_conditional
./bad_substitutions_breaks_conditional: line 6: x has value ${x@q} - stop now!:
bad substitution
running
./bad_substitutions_breaks_conditional: line 11: x has value ${x@q} - stop
now!: bad substitution
still running
./bad_substitutions_breaks_conditional: line 15: x has value ${x@q} - stop
now!: bad substitution
