On Mon, 1 Sept 2025 at 04:35, Maria wrote:
> Bash will crash with exit code 141.
For complicated historical reasons, when a process is killed by a signal,
the parent shell pretends that it exited with a status of 128 plus the
terminating signal number. This is why you see what looks like "exit
Avoid test failure if user's .bashrc produces any output.
Avoid writing test commands to users's .bash_history file.
---
tests/execscript | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/execscript b/tests/execscript
index aad37be4..0e652b1a 100644
--- a/tests/execscript
+
On Aug 31 2025, Maria wrote:
> Can you please link to the manual page or other source that
> documents this behavior?
>From help trap:
$ kill -PIPE $$
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something comple
On Aug 31 2025, Maria wrote:
> Please try the command I provided, particularly the one that starts
> with "for". I tried the input you provided, and indeed it is just
> the subprocess that exits, but with my input, it is Bash itself that
> exits, not the subprocess.
That's correct behaviour. The
On Sunday, August 31st, 2025 at 4:15 PM, Andreas Schwab
wrote:
> That's correct behaviour. The shell executes the compound command and
> the containing builtin commands directly and thus receives the signal,
> as soon as it produces more output than what fits in the pipe buffer.
Can you please l
On Sunday, August 31st, 2025 at 4:11 PM, G. Branden Robinson
g.branden.robin...@gmail.com wrote:
> I wonder if the `lastpipe` shell option is implicated.
I checked with `shopt`, and it reports `lastpipe` to be off.
At 2025-08-31T19:20:58+, Maria wrote:
> On Sunday, August 31st, 2025 at 3:12 PM, Andreas Schwab
> wrote:
> > On Aug 31 2025, Maria wrote:
> > > When I redirect the output of a command that sleeps into a process
> > > substitution with a process that finishes immediately (like "echo"
> > > or a
On Sunday, August 31st, 2025 at 3:12 PM, Andreas Schwab
wrote:
> On Aug 31 2025, Maria wrote:
>
> > When I redirect the output of a command that sleeps into a process
> > substitution with a process that finishes immediately (like "echo" or
> > a process that doesn't exist), after the first slee
On Aug 31 2025, Maria wrote:
> When I redirect the output of a command that sleeps into a process
> substitution with a process that finishes immediately (like "echo" or
> a process that doesn't exist), after the first sleep, Bash will crash
> with exit code 141.
This is n
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection
-Wformat -Werror=format-se
Maybe it changed between 5.3 rc2 and 5.3 release. 5.3 rc2 was compiled as is;
no
local changes.
Anyway, it is what it is. Doesn't matter. Not worth arguing about.
=
Please do not send me replies to my posts on the
On Sun, Aug 31, 2025 at 07:49:57 -0600, Stan Marsh wrote:
> But here's the thing: As far as I can tell, extglob is on-by-default - in all
> the
> versions of bash that I was able to test - so I don't understand why OP is
> messing
> around with turning it on and off. Or why Greg is talking about
On Aug 31 2025, Stan Marsh wrote:
> But here's the thing: As far as I can tell, extglob is on-by-default
No, it isn't.
$ bash -c 'shopt -p extglob'
shopt -u extglob
$ bash --version
GNU bash, version 5.3.3(1)-release (x86_64-suse-linux-gnu)
Copyright (C) 2025 Free Software Foundation, Inc.
Licen
On Sun, Aug 31, 2025 at 07:49:57AM -0600, Stan Marsh wrote:
> (>> == pourko, > == Greg)
>
> >> Sorry, Greg, but this is no "compound" command, these are separate
> >> commands:
> >>
> >> $ shopt -s extglob; echo !(this)
>
> >That is another case where it fails, correct.
>
> >However, in your o
(>> == pourko, > == Greg)
>> Sorry, Greg, but this is no "compound" command, these are separate commands:
>>
>> $ shopt -s extglob; echo !(this)
>That is another case where it fails, correct.
>However, in your original email, you did indeed have the shopt inside
>a compound command. That's why
On Sun, Aug 31, 2025 at 14:13:17 +0200, pou...@tutamail.com wrote:
> Aug 30, 2025, 12:08 by g...@wooledge.org:
>
> > All of these are compound commands, and must be parsed as a whole before
> > executing any of the simple commands contained inside them.
> >
>
> Sorry, Greg, but this is no "comp
Aug 30, 2025, 12:08 by g...@wooledge.org:
> This is the expected behavior.
>
I am actually disturbed by two problems here:
One is the brutal abort of the whole script on a "syntax error",
and the other is the suggestion that this...
$ shopt -s extglob; echo !(this)
...can behave differently t
Aug 30, 2025, 12:08 by g...@wooledge.org:
> All of these are compound commands, and must be parsed as a whole before
> executing any of the simple commands contained inside them.
>
Sorry, Greg, but this is no "compound" command, these are separate commands:
$ shopt -s extglob; echo !(this)
>
18 matches
Mail list logo
