Re: [ping] declare -c still undocumented.
Date:Mon, 16 Nov 2020 22:59:39 -0500 From:wor...@alum.mit.edu (Dale R. Worley) Message-ID: <87ft58ws44@hobgoblin.ariadne.com> | Although I must say, I can't recall off the top of my head what Un*x | utility best capitalizes the first letter of a string. sed works, though it takes a multi-line program to do it. kre
Re: is it a bug
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
> or (to reproduce error):
> an_alias='res=() t=""
>for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
> for i in 1; do echo hi; done'
unicorn:~$ foo
bash: syntax error near unexpected token `;'
unicorn:~$ alias bar='a=()
> b=""
> for i in 1; do echo hi; done'
unicorn:~$ bar
hi
use of set -e inside parenthesis and conditionnal second command
Configuration Information [Automatically generated, do not change]: 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$ uname output: Linux zebulon 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 3 Release Status: release Description: I'm not sure this is actually a bug since dash act the same way but it's quite unexpected for the average user and the manual suggests it should not act like this. The solution may be to improve the manual instead of fixing the software. Please, consider the 3 next lines #1 pierre@zebulon: ~ $ (set -e ; echo A ; false ; echo B ) ; echo C.$? A C.1 #Works fine #2 pierre@zebulon: ~ $ (set -e ; echo A ; false ; echo B ) && echo C.$? A B C.0 #Surprising #3 pierre@zebulon: ~ $ bash -c 'set -e ; echo A ; false ; echo B ' && echo C.$? A #This line works like I was expecting for #2 Repeat-By: already explained in description Fix: no idea. If it's not a bug, I think the manual should explain the difference between #2 and #3 in section 3.2.3 and 3.2.4.3
Re: use of set -e inside parenthesis and conditionnal second command
On Tue, Nov 17, 2020 at 09:35:35AM +0100, Pierre Colombier via Bug reports for the GNU Bourne Again SHell wrote: > I'm not sure this is actually a bug since dash act the same way but > it's quite unexpected for the average user Agreed! The behavior of set -e is extremely surprising, and people should stop expecting it to make intuitive sense. The best way to avoid being surprised by it is to stop using it altogether. You will be much happier. > and the manual suggests it should > not act like this. It is virtually impossible to document the behavior of set -e in a way that a human brain can understand, because the behavior is so nonsensical. Can you cite a specific sentence in the manual that is incorrect? > pierre@zebulon: ~ $ (set -e ; echo A ; false ; echo B ) && echo C.$? > A > B > C.0 > > #Surprising This was alerady explained a few days ago. You've got a compound command of the form X && Y. The effect of set -e is suppressed in this compound command, except if Y fails. The shell does not exit if the command that fails is part of the command list immediately following a while or until keyword, part of the test following the if or elif reserved words, part of any command executed in a && or || list except the command following the final && or ||, any command in a pipeline but the last, or if the command's return value is being inverted with !. I am guessing you are surprised that "echo B" was executed. But the documentation says that set -e doesn't apply to "any command executed in a && or || list except [the last one]". The fact that you spawned a subshell doesn't change that. The subshell is a fork() of the script, so it inherits all of the internal knowledge of the parent process. The left hand side knows it's part of a && list and therefore doesn't honor set -e. In the example that I snipped, you replaced the subshell with an explicit "bash -c ...", which is NOT a subshell, and does not inherit the internal knowledge of the parent process. In that example, the left hand side doesn't know that it's part of a && list in a calling scope, so it doesn't know it should suppress set -e. So, you get a different result. Seriously, set -e is not a good thing. Stop using it.
Re: is it a bug
$ alias x='a=() foo echo $a' $ x foo $ declare -p a declare -a a=([0]="foo") 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: use of set -e inside parenthesis and conditionnal second command
On 17/11/2020 at 16:00, Ilkka Virta wrote: Now, perhaps that could use a note explicitly saying this also means subshells, even though they may have set -e in effect independently of the main shell. The part explaining subshells (3.7.3 Command Execution Environment) could perhaps also use a mention of that caveat, since it does mention set -e already, though in the context of command substitution. So it is clearly not a bug. The shell -e or bash's errexit option is a problematic tools with hard to understand side-effects. I can't figure a use-case where a shell would appropriately straight exit without any cleanup or fallback. This feature deserves a bold disclaimer to think twice before using it rather than explicit error handing. -- Léa Gris
Re: use of set -e inside parenthesis and conditionnal second command
Greg Wooledge: > The behavior of set -e is extremely surprising, and people should > stop expecting it to make intuitive sense. The best way to avoid being > surprised by it is to stop using it altogether. Has it ever been considered to add something like 'shopt -s composable_compound'? Roughly meaning "execution and exit status of a compound command are not changed by surrounding context (in the sense of logical operators, or being the condition of an if statement etc.)" That, together with 'set -e -o pipefail; shopt -s inherit_errexit' seems like it would go a long way towards easier error handling. Rusty signature.asc Description: PGP signature
Re: use of set -e inside parenthesis and conditionnal second command
On Tue, Nov 17, 2020 at 4:07 PM Pierre Colombier via Bug reports for the GNU Bourne Again SHell wrote: > #2 > pierre@zebulon: ~ $ (set -e ; echo A ; false ; echo B ) && echo C.$? > #3 > pierre@zebulon: ~ $ bash -c 'set -e ; echo A ; false ; echo B ' && echo > C.$? If it's not a bug, I think the manual should explain the difference > between #2 and #3 in section 3.2.3 and 3.2.4.3 > Technically, I suppose the description of set -e already says that (4.3.1 The Set Builtin): "If a compound command or shell function executes in a context where -e is being ignored, none of the commands executed within the compound command or function body will be affected by the -e setting, even if -e is set and a command returns a failure status. " The subshell (set -e; echo...) is a compound command, and it executes as a non-final part of the && list, so none of the commands within are affected by set -e. The other command explicitly invoking bash is not a subshell or any other type of compound command. Now, perhaps that could use a note explicitly saying this also means subshells, even though they may have set -e in effect independently of the main shell. The part explaining subshells (3.7.3 Command Execution Environment) could perhaps also use a mention of that caveat, since it does mention set -e already, though in the context of command substitution. https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html https://www.gnu.org/software/bash/manual/html_node/Command-Execution-Environment.html
Re: is it a bug
On 11/17/20 7:56 AM, Greg Wooledge wrote:
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
or (to reproduce error):
an_alias='res=() t=""
for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
for i in 1; do echo hi; done'
unicorn:~$ foo
bash: syntax error near unexpected token `;'
unicorn:~$ alias bar='a=()
b=""
for i in 1; do echo hi; done'
unicorn:~$ bar
hi
Interesting. Thanks for the simple reproducer, both of you. I'll take a
look after bash-5.1 is out.
--
``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/
No longer receifing nntp feed from here
Anyone to look why this is no longer connected to the bug-bash@gnu.org ML? -- Lea Gris
Re: use of set -e inside parenthesis and conditionnal second command
Rusty Bird writes: >> The behavior of set -e is extremely surprising [...] > Has it ever been considered to add something like 'shopt -s > composable_compound'? Roughly meaning "execution and exit status of a > compound command are not changed by surrounding context (in the sense > of logical operators, or being the condition of an if statement etc.)" > > That, together with 'set -e -o pipefail; shopt -s inherit_errexit' > seems like it would go a long way towards easier error handling. Better than figuring out how to create a modification of "-e", it's probably better to design "easier error handling" from scratch, and define an entirely new option to activate it. Dale
