5.2.37: bg(1)ed job then only runs partially

Hello. So first: this thread must not even start if the answer is "bash justs sends a signal to the job's entire process group, if the programs do not properly deal with that it cannot help that". (ogg123 in particular is known to have signal issues.) This just in case possible changes brought in

Re: posix vs default mode nonsense

On Mon, Oct 21, 2024 at 5:07 PM Lawrence Velázquez wrote: > > On Mon, Oct 21, 2024, at 4:23 PM, Zachary Santer wrote: > > On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey wrote: > >> > >> That changed to an application requirement in 2001. > > > > Pardon my ignorance, but as an "application requiremen

Re: posix vs default mode nonsense

On Mon, Oct 21, 2024, at 4:23 PM, Zachary Santer wrote: > On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey wrote: >> >> On 10/21/24 9:54 AM, Robert Elz wrote: >> > From the earlier message (just replying to this one to get the >> > new Subject: which fits better)... >> > >> > zsan...@gmail.com said: >

Re: posix vs default mode nonsense

On Mon, Oct 21, 2024 at 11:50 AM Chet Ramey wrote: > > On 10/21/24 12:15 AM, Zachary Santer wrote: > > > > The nontrivial stuff I do is still being run by bash 4.2 at the > > moment, and I'm not willing to give up procsubs. > > Probably something to take up with your distro (Red Hat/Centos, right?

Re: [PATCH] isearch: fix with HANDLE_MULTIBYTE && LC_ALL=C

On 10/18/24 6:50 PM, Grisha Levit wrote: HISTFILE= INPUTRC=/ LC_ALL=C bash --norc -in <<< $'\cR.' Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://t

Re: 'wait -n' with and without id arguments

On 10/20/24 8:51 PM, Zachary Santer wrote: On item 58: My external 'kill' is from Cygwin Utilities, naturally, but its -l does what bash's 'kill -l' does in POSIX mode and its -L does something similar to what bash's 'kill -l' does in default mode. Could POSIX-mode bash 'kill -L' still give the

Re: posix vs default mode nonsense

On 10/21/24 9:54 AM, Robert Elz wrote: From the earlier message (just replying to this one to get the new Subject: which fits better)... zsan...@gmail.com said: | I can work around function names needing to be valid shell 'name's by That one bash could easily fix if it wanted to, there's ne

Re: posix vs default mode nonsense

On 10/21/24 12:15 AM, Zachary Santer wrote: Item 8 is just odd and is on the verge of being a dealbreaker. Not to go off on another tangent, but what on Earth? AFAICT it's the non-POSIX-mode Bash behavior that is unusual. While all shells will have treat single quotes as literal here:

Re: ${param@a} should bypass unbound variable check or be processed ahead of it.

On Mon, Oct 14, 2024 at 2:57 AM Chet Ramey wrote: > > I'll consider it, but I'm not eager to carve out more exceptions for > `set -u'. Checking for unbound_vars_is_error can be done earliest if you worry about additional runtime weight. It makes the code for disabled `set -u` instances optimal b

Re: IFS whitespace definition

On 10/21/24 10:13 AM, Robert Elz wrote: | The word splitting section wasn't quite | as rigorous as the current version's, but it referenced this definition. Actually, it didn't, which was one of that section's many problems. What it said was The term ``IFS white space'' is used

Re: ${param@a} should bypass unbound variable check or be processed ahead of it.

On Mon, Oct 21, 2024 at 11:08 AM Grisha Levit wrote: > > Maybe just adjusting the latter to also expand to the variable's attributes > would suffice. var[@] refers to all the elements and not the variable itself so I'll find that painful to use. The solution to check want_attributes is simpler.

Re: IFS whitespace definition

Date:Fri, 18 Oct 2024 16:28:06 -0400 From:Chet Ramey Message-ID: | At the time (previous edition of the standard), POSIX defined whitespace | as "In the POSIX locale, white space consists of one or more ( | and characters), , , , | and characters." Yes,

Re: posix vs default mode nonsense

>From the earlier message (just replying to this one to get the new Subject: which fits better)... zsan...@gmail.com said: | I can work around function names needing to be valid shell 'name's by That one bash could easily fix if it wanted to, there's never been a POSIX requirement that only "n

[bug #66363] "test" builtin command, -a arg not working as expected

URL: Summary: "test" builtin command, -a arg not working as expected Group: The GNU Bourne-Again SHell Submitter: None Submitted: Mon 21 Oct 2024 10:18:53 AM UTC Category: Non