Next word of alias to alias that end with is not checked for alias

2023-01-12 Thread anonymous4feedb...@outlook.com
Dear dir or madam, For the following script: alias a1='echo ' alias a2=a1 alias foo=bar a2 foo bash outputs ‘foo’, instead of ‘bar’. GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) on archlinux as windows subsystem for linux Thanks.

Re: errexit is not suspended in a pipeline

2023-01-12 Thread Chet Ramey
On 1/11/23 11:22 PM, Quinn Grier wrote: I see. I had mistakenly thought that Bash's set -e description was definitively listing the contexts in which set -e is ignored, not just contexts in which set -e may not have the intended effect. It lists the scenarios where the shell will not exit. --

Re: Next word of alias to alias that end with is not checked for alias

2023-01-12 Thread Chet Ramey
On 1/11/23 10:43 PM, anonymous4feedb...@outlook.com wrote: Dear dir or madam, For the following script: alias a1='echo ' alias a2=a1 alias foo=bar a2 foo bash outputs ‘foo’, instead of ‘bar’. Bash has never extended the `expand next word' semantics to multiple-level alias expansion like this,

Re: Next word of alias to alias that end with is not checked for alias

2023-01-12 Thread Greg Wooledge
On Thu, Jan 12, 2023 at 03:43:15AM +, anonymous4feedb...@outlook.com wrote: > Dear dir or madam, > > For the following script: > alias a1='echo ' > alias a2=a1 > alias foo=bar > a2 foo > bash outputs ‘foo’, instead of ‘bar’. > > GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) on arc

Re: Next word of alias to alias that end with is not checked for alias

2023-01-12 Thread Robert Elz
Date:Thu, 12 Jan 2023 10:56:33 -0500 From:Chet Ramey Message-ID: <0f03dd45-3e1a-54b1-f884-d3fb2c1c7...@case.edu> | Bash has never extended the `expand next word' semantics to multiple-level | alias expansion like this, and no one has missed it. Bash is unique amo

Re: Next word of alias to alias that end with is not checked for alias

2023-01-12 Thread Greg Wooledge
On Fri, Jan 13, 2023 at 01:59:55AM +0700, Robert Elz wrote: > Date:Thu, 12 Jan 2023 10:56:33 -0500 > From:Chet Ramey > Message-ID: <0f03dd45-3e1a-54b1-f884-d3fb2c1c7...@case.edu> > > | Bash has never extended the `expand next word' semantics to multiple-level > |

SIGINT handling during async functions

2023-01-12 Thread Tycho Kirchner
Hi, we found quite some inconsistency and weirdness in the handling of SIGINT's during async function calls and were wondering, whether those are expected. All calls were executed from a script with jobcontrol turned off (set +m) while pressing Ctrl+C shortly afterwards. In summary: The main IN

Re: SIGINT handling during async functions

2023-01-12 Thread Robert Elz
Date:Fri, 13 Jan 2023 00:34:02 +0100 From:Tycho Kirchner Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de> | we found quite some inconsistency and weirdness | in the handling of SIGINT's during async function calls Not inconsistent or weird, and has noth

Re: SIGINT handling during async functions

2023-01-12 Thread Robert Elz
Oh, the differences in what trap -p is printing is because of special case handling for trap in a subshell environment, when the trap command is the first (maybe only) command executed (details vary between shells). That is mostly intended to allow T=$(trap -p) to work, but is usually applied to a

Re: SIGINT handling during async functions

2023-01-12 Thread Tycho Kirchner
Am 13.01.23 um 03:02 schrieb Robert Elz: Date:Fri, 13 Jan 2023 00:34:02 +0100 From:Tycho Kirchner Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de> | we found quite some inconsistency and weirdness | in the handling of SIGINT's during async func