Re: executes statement after "exit"
dude u didnt get, in your example : is already the cmd
therenis no 'exit cmd' in your code
only exit as arg to :
On Fri, Apr 15, 2022, 20:36 Frank Heckenbach
wrote:
> > > #!/bin/bash
> > > : $((08 + 0)); exit
> > > echo "Should not get here."
> >
> > It never executes `exit'.
> >
> > The explanation in
> > https://lists.gnu.org/archive/html/bug-bash/2022-04/msg00010.html
> applies here.
> >
> > The arithmetic syntax error (invalid octal constant) results in a word
> > expansion error (the $((...)) ), which causes the shell to abort
> execution
> > of the current command (the command list)
>
> Current command means command list? Is this actually documented
> somewhere?
>
> E.g., in "3.5.6 Process Substitution" the manual says:
> "The process list is run asynchronously, and its input or output
> appears as a filename. This filename is passed as an argument to the
> current command as the result of the expansion."
>
> So if "current command" is the command list, in
>
> sleep 3; : <(echo foo >&2)
>
> shouldn't it start the "echo" before the "sleep" (in order to pass
> its stdout as a filename to the command list)? It doesn't seem to do
> so. So here, "current command" apparently means a simple command
> (or in other cases, a compound command), but not a command list.
>
> > and jump back to the top level
> > to continue execution with the next command (echo).
>
> Let't see. This is a command list, so according to your explanation,
> due to the expansion error, neither the "exit" nor the "echo" is
> run:
>
> : $((08 + 0)); exit; echo "Should not get here."
>
> Alright. Now, in "3.2.4 Lists of Commands" it says:
>
> "A sequence of one or more newlines may appear in a list instead of a
> semicolon to delimit commands."
>
> So let's do this for the latter semicolon, resulting in:
>
> : $((08 + 0)); exit
> echo "Should not get here."
>
> According to the above, this should still be one command list, so
> the "echo" shouldn't run either, but it does.
>
> > POSIX requires the shell to exit on a word expansion error, which bash
> does
> > in posix mode.
>
> This actually seems the saner behaviour rather than continuing at some
> arbitrary point -- which I guess is well-defined in some sense, but
> really unobvious to the programmer and very fragile since it changes
> when a block is moved to a function, put inside an "if"-statement or
> just has the formatting (";" vs. newline) changed ...
>
>
Re: bash seems confused about it's state after unclosed single quotes in nested command substitution
On 4/15/22 11:52 AM, Martin Schulte wrote: Hello bash-bughunters, please consider the following interactive lines: It turns out that running it in an interactive shell is the key. $ echo $BASH_VERSION 5.1.4(1)-release $ uname -a Linux t1 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux $ echo $BASH_VERSION 5.1.4(1)-release $ sleep $(expr 60 - $(date +%s')) ; date bash: command substitution: line 417: unexpected EOF while looking for matching `'' bash: command substitution: line 418: syntax error: unexpected end of file bash: unexpected EOF while looking for matching `)' $ At this point it looks as if bash has encountered the problem and thus not executed the command line - fine. Things get strange when you enter a command, e.g. echo: $ echo To get out of this you can enter the missing single quote followed by two closing braces: (Well, parens ;-) ) Because those are the missing delimiters. The problem is actually bash jumping back to the top level because it's trying to find the correct delimiter to store the line in the command-oriented history, not anything to do with the parser per se. It works in bash-5.2, which does command substitution parsing completely differently. -- ``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: executes statement after "exit"
On 4/15/22 2:34 PM, Frank Heckenbach wrote:
#!/bin/bash
: $((08 + 0)); exit
echo "Should not get here."
It never executes `exit'.
The explanation in
https://lists.gnu.org/archive/html/bug-bash/2022-04/msg00010.html applies here.
The arithmetic syntax error (invalid octal constant) results in a word
expansion error (the $((...)) ), which causes the shell to abort execution
of the current command (the command list)
Current command means command list?
No, of course not. It means the shell command currently being executed. In
this case, that's a command list.
Let's go through it step by step. Bash always reads at least one line from
the input source, and parses all the commands on that line before executing
any of them. So in this case, we have the line
: $((08 + 0)); exit
which is parsed into a command list (a compound command) containing two
simple commands. Bash executes the command list, so the list is the current
command.
The top level in this scenario is the point in the input source where bash
has stopped reading because it has read and parsed a complete command and
can execute it -- the next character it will read at the top level is the
`e' in `echo'.
So bash attempts to execute the first simple command in the list, and
begins by performing word expansion on the arguments to `:'. It encounters
an expansion error, abandons execution of the command list, and jumps to
the top level to continue execution.
This is roughly equivalent to what happens when the shell is interactive.
It returns to its top-level parsing loop, prints a new prompt, and reads
and executes a new command.
So if "current command" is the command list, in
sleep 3; : <(echo foo >&2)
shouldn't it start the "echo" before the "sleep" (in order to pass
its stdout as a filename to the command list)?
No. That's not how the grammar works.
and jump back to the top level
to continue execution with the next command (echo).
Let't see. This is a command list, so according to your explanation,
due to the expansion error, neither the "exit" nor the "echo" is
run:
: $((08 + 0)); exit; echo "Should not get here."
Alright. Now, in "3.2.4 Lists of Commands" it says:
"A sequence of one or more newlines may appear in a list instead of a semicolon to
delimit commands."
So let's do this for the latter semicolon, resulting in:
: $((08 + 0)); exit
echo "Should not get here."
According to the above, this should still be one command list, so
the "echo" shouldn't run either, but it does.
No, because the shell always reads lines from the input and parses them.
It only reads more than one line from the input if it needs it to parse
some compound command. A simple example is
{
: $((08 + 0)); exit
echo "Should not get here."
}
where the shell will read both lines and parse them as a single list
because it needs to read the final close brace to complete the compound
command.
--
``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: executes statement after "exit"
On 4/16/22 9:50 AM, Alex fxmbsw7 Ratchev wrote: dude u didnt get, in your example : is already the cmd therenis no 'exit cmd' in your code only exit as arg to : No, you missed the `;' separator: > > : $((08 + 0)); exit -- ``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: Crash with 5.2 beta in compgen
On 4/16/22 1:45 AM, Sam James wrote: Bash Version: 5.2 Patch Level: 0 Release Status: beta Description: Bash crashes when running compgen -c -X a. Repeat-By: # bash -c "compgen -c -X a" Segmentation fault (core dumped) I can't reproduce this. I wonder if it has to do with resource limits. -- ``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: Crash with 5.2 beta in compgen
On Apr 16 2022, Chet Ramey wrote: > On 4/16/22 1:45 AM, Sam James wrote: > >> Bash Version: 5.2 >> Patch Level: 0 >> Release Status: beta >> Description: >> Bash crashes when running compgen -c -X a. >> Repeat-By: >> # bash -c "compgen -c -X a" >> Segmentation fault (core dumped) > > I can't reproduce this. I wonder if it has to do with resource limits. It crashes in strchr due to NULL pointer (which comes from rl_completer_word_break_characters). #0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32 #1 0x5561b7f5 in mbschr (s=0x0, c=47) at mbschr.c:56 #2 0x555b1d7e in quote_word_break_chars ( text=0x55897b70 "/usr/bin/atoc_conv") at bashline.c:4150 #3 bash_quote_filename (s=s@entry=0x55897b30 "/usr/bin/atoc_conv", rtype=rtype@entry=1, qcp=qcp@entry=0x7fffd60f "") at bashline.c:4353 #4 0x555b2dd4 in executable_completion (searching_path=1, filename=0x55897b30 "/usr/bin/atoc_conv") at bashline.c:1951 #5 command_word_completion_function (hint_text=, state=) at bashline.c:2385 #6 0x77ba0186 in rl_completion_matches ( text=text@entry=0x556410e7 "", entry_function=0x555b2276 ) at ../complete.c:2219 #7 0x555b8164 in gen_action_completions ( text=text@entry=0x556410e7 "", cs=) at pcomplete.c:856 #8 0x555b74bd in gen_compspec_completions ( cs=cs@entry=0x5588e0d0, cmd=cmd@entry=0x55640771 "compgen", word=word@entry=0x556410e7 "", start=start@entry=0, end=end@entry=0, foundp=foundp@entry=0x0) at pcomplete.c:1333 #9 0x555cbdb2 in compgen_builtin (list=) at ./complete.def:721 -- 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: Crash with 5.2 beta in compgen
> On 16 Apr 2022, at 17:11, Chet Ramey wrote: > > On 4/16/22 1:45 AM, Sam James wrote: > >> Bash Version: 5.2 >> Patch Level: 0 >> Release Status: beta >> Description: >> Bash crashes when running compgen -c -X a. >> Repeat-By: >># bash -c "compgen -c -X a" >>Segmentation fault (core dumped) > > I can't reproduce this. I wonder if it has to do with resource limits. > Suspect Andreas' reply may be more insightful, but was able to reproduce this in a fresh Debian stable chroot too, created with debootstrap. root@debian-stable:~/bash-5.2-beta# /usr/local/bin/bash -c "compgen -c -X a" Segmentation fault (core dumped) signature.asc Description: Message signed with OpenPGP
