Hi here,

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o pgid= $$ | egrep -o [0-9]+); exit 1' 2


Then when the script is running, when I hit the control-c, I just noticed the following information given on the screen:

blabla (Here is the normal information given by the script when running).
^C

This issue did not occur until I upgraded to this version of the operating system. I'm very confused by this behavior.

Any comments and tips will be appreciated.

Regards,
Zhao

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 4 Dec 2022 00:47:02 -0800 (PST), "[email protected]" <[email protected]> wrote:

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o pgid= $$ | egrep -o [0-9]+); exit 1' 2

Then when the script is running, when I hit the control-c,
I just noticed the following information given on the screen:

blabla (Here is the normal information given by the script when running).
^C

This issue did not occur until I upgraded to this version of the
operating system. I'm very confused by this behavior.

With GNU bash, version 5.0.3(1)-release
(arm-unknown-linux-gnueabihf) I get:

blah
blah
^C
*** Ouch! Exiting ***
Terminated
$

So you will have to read the release notes of bash between your
previous version and the current one.

--
Regards,
Kees Nuyt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"[email protected]" <[email protected]> writes:

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

Same here.

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o
pgid= $$ | egrep -o [0-9]+); exit 1' 2

What's all the ps and egrep stuff for? Isn't the net effect just $$?

Then when the script is running, when I hit the control-c, I just
noticed the following information given on the screen:

blabla (Here is the normal information given by the script when
running). ^C

This issue did not occur until I upgraded to this version of the
operating system. I'm very confused by this behavior.

Presumably the issue is that the trap does not work, but it does for
me. Is Ctrl-C sending the right signal?

Can you post a minimal example that fails for you? This example:

#!/bin/bash

trap 'echo -en "\n*** Ouch! Exiting ***\n"; exit 1' 2

while true; do
echo blah
done

works for me:

$ ./script
blah
blah
blah
blah
blah
blah
^C./script: line 6: echo: write error: Interrupted system call

*** Ouch! Exiting ***

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/4/2022 2:47 AM, [email protected] wrote:

Hi here,

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o pgid= $$ | egrep -o [0-9]+); exit 1' 2

Then when the script is running, when I hit the control-c, I just noticed the following information given on the screen:

blabla (Here is the normal information given by the script when running).
^C

This issue did not occur until I upgraded to this version of the operating system. I'm very confused by this behavior.

Any comments and tips will be appreciated.

Regards,
Zhao

The most common source of confusion in this area is, I think, when
people are running a shell that calls another command in a sub-shell.
They send an interrupt and the sub-shell gets the interrupt but the
subshell traps the interrupt to handle it itself and then doesn't exit
with an interrupt exit status so the calling shell where you expect to
see an interrupt trapped doesn't fire because that shell doesn't know an interrupt happened.

We can't help you diagnose a problem in a script given just 1 line of
the script though - create and provide a **MINIMAL** complete sample
script that has this problem and then we can help you.

Also, if you google for things like "bash interrupt subshell" you'll get
some hits with more info on this topic. Also see https://mywiki.wooledge.org/SignalTrap.

Ed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, December 5, 2022 at 12:13:50 AM UTC+8, Ben Bacarisse wrote:

"[email protected]" <[email protected]> writes:

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

Same here.

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o
pgid= $$ | egrep -o [0-9]+); exit 1' 2

What's all the ps and egrep stuff for? Isn't the net effect just $$?

I've a bunch of other processes spawned from this script, and I hope to kill them all, so that the orphan process will not be left behind.

Then when the script is running, when I hit the control-c, I just
noticed the following information given on the screen:

blabla (Here is the normal information given by the script when
running). ^C

This issue did not occur until I upgraded to this version of the
operating system. I'm very confused by this behavior.

Presumably the issue is that the trap does not work, but it does for
me. Is Ctrl-C sending the right signal?

Can you post a minimal example that fails for you? This example:

#!/bin/bash

trap 'echo -en "\n*** Ouch! Exiting ***\n"; exit 1' 2

while true; do
echo blah
done

works for me:

$ ./script
blah
blah
blah
blah
blah
blah
^C./script: line 6: echo: write error: Interrupted system call

*** Ouch! Exiting ***

I observed the same behavior as you. But my real original script is rather complicated, and it will take some time to work out a minimal example.

--
Ben.

Zhao

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"[email protected]" <[email protected]> writes:

On Monday, December 5, 2022 at 12:13:50 AM UTC+8, Ben Bacarisse wrote:

"[email protected]" <[email protected]> writes:

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

Same here.

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o
pgid= $$ | egrep -o [0-9]+); exit 1' 2

What's all the ps and egrep stuff for? Isn't the net effect just $$?

I've a bunch of other processes spawned from this script, and I hope
to kill them all, so that the orphan process will not be left behind.

Ed Morton called it! Did you read his reply?

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, December 5, 2022 at 9:15:57 AM UTC+8, Ben Bacarisse wrote:

"[email protected]" <[email protected]> writes:

On Monday, December 5, 2022 at 12:13:50 AM UTC+8, Ben Bacarisse wrote:

"[email protected]" <[email protected]> writes:

On Ubuntu 22.10, I'm using the following shipped bash version:

$ bash --version
GNU bash, version 5.2.2(1)-release (x86_64-pc-linux-gnu)

Same here.

In my case, I've a bash script which has the following line in it:

trap 'echo -en "\n*** Ouch! Exiting ***\n"; sudo kill -- -$(ps -o
pgid= $$ | egrep -o [0-9]+); exit 1' 2

What's all the ps and egrep stuff for? Isn't the net effect just $$?

I've a bunch of other processes spawned from this script, and I hope
to kill them all, so that the orphan process will not be left behind.

Ed Morton called it! Did you read his reply?

I've read Ed Morton's valuable reply and am trying to find the root of the problem based on his comments. Still, it seems like a needle-in-a-haystack problem, at least for now.

--
Ben.

Zhao

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)