Bash 5.1: Make shell_script_filename available to startup files

Currently, only the script's arguments are passed as positional parameters. For compatibility reasons, $0 cannot be used to also pass the script's filename, so I'm creating a new BASH_SCRIPT variable instead. Below is a heavily simplified test case. The goal is to stop it from asking who you

Bash 5.1: accept loadable build fix

typemax.h states it should be included after config.h, limits.h, stdint.h, and inttypes.h. But, on my system (with glibc 2.32), accept.c ends up including after typemax.h, via the sequence ... accept.c -> loadables.h -> builtins.h -> general.h -> ... resulting in a compile failure. Below is

Bash 5.1: shadow tree build fix

These changes are needed when building bash in a symlink shadow tree of a read-only source tree. While there, deal with a minor typo. Please Reply-To-All. Thanks. Marc. -- --- bash-5.1/Makefile.in +++ devel-5.1/Makefile.in @@ -649,6 +649,7 @@ ${GRAM_H}: y.tab.h y.tab.c: parse.y # -if

Bash 5.1: --disable-multibyte build fix

Mostly typos. Please Reply-To-All. Thanks. Marc. -- --- bash-5.1/lib/glob/glob.c +++ devel-5.1/lib/glob/glob.c @@ -119,10 +119,10 @@ void udequote_pathname PARAMS((char *)); #if HANDLE_MULTIBYTE void wcdequote_pathname PARAMS((wchar_t *)); static void wdequote_pathname PARAMS((char *)); +sta

A bash bug? sh_malloc missing

Hi, I just checked out the "latest" bash from the repo at savanna.gnu.org and am having build problems. I have tried --with-gnu-malloc and it's alias and also tried building without any malloc parameters in configure without success. Enclosed below is what I'm seeing. I have a full build log a

Re: a few bugs, i hope you can read it

On Mon, Feb 01, 2021 at 04:34:17PM +0100, Alex fxmbsw7 Ratchev wrote: > and as i wrote a couple of times, my .c skills are not sufficial in bug > hunting to make a reproducer rather than main case It has nothing to do with your skill level in C. Nobody expects you to actually fix the bugs -- just

Re: a few bugs, i hope you can read it

On 2/1/21 10:34 AM, Alex fxmbsw7 Ratchev wrote: and as i wrote a couple of times, my .c skills are not sufficial in bug hunting to make a reproducer rather than main case You don't need to know C programming to take a shell script and reduce it to the shortest example that shows your point. --

Re: Ordering bug when handling redirection with file descriptors

1 Şubat 2021 Pazartesi tarihinde Chet Ramey yazdı: > > I'm not changing it now, > after 30 years. > Not even in posix mode? -- Oğuz

Re: Ordering bug when handling redirection with file descriptors

On 2/1/21 10:37 AM, Oğuz wrote: 1 Şubat 2021 Pazartesi tarihinde Chet Ramey > yazdı: I'm not changing it now, after 30 years. Not even in posix mode? It's not a simple change, and I have no idea how much code depends on the existing behavior. -- ``The ly

Re: a few bugs, i hope you can read it

i can put up three files i just wanted complecy On Mon, Feb 1, 2021, 16:08 Chet Ramey wrote: > On 1/31/21 9:26 PM, Alex fxmbsw7 Ratchev wrote: > > ( http://ix.io/2NUp ) - sadly i dont have the depaster ready, some loop > > deep logic faukts > > > > bash-5.1# n=1 bash paster $( < thefiles ) > > +

Re: a few bugs, i hope you can read it

and as i wrote a couple of times, my .c skills are not sufficial in bug hunting to make a reproducer rather than main case On Mon, Feb 1, 2021, 16:31 Alex fxmbsw7 Ratchev wrote: > i can put up three files > i just wanted complecy > > On Mon, Feb 1, 2021, 16:08 Chet Ramey wrote: > >> On 1/31/21

Re: a few bugs, i hope you can read it

On 1/31/21 9:26 PM, Alex fxmbsw7 Ratchev wrote: ( http://ix.io/2NUp ) - sadly i dont have the depaster ready, some loop deep logic faukts bash-5.1# n=1 bash paster $( < thefiles ) ++ paste BEGIN ++ How about just a simple reproducer, instead of putting a bunch of stuff in a single message in a

Re: Ordering bug when handling redirection with file descriptors

On 2/1/21 12:32 AM, Oğuz wrote: .. but, I'm not sure about this case: $ set -o posix $ a=`uname >&4` env 4>&1 bash: 4: Bad file descriptor a= Bash always performs word expansions and variable assignments preceding commands before redirections, and always has. I'm not changi

Re: Ordering bug when handling redirection with file descriptors

On 1/31/21 3:40 PM, Érico Nogueira wrote: Hi! I have the below test case which works with dash, zsh, and has been reported to work at least up to bash 4.4.12. After 4.4.23 it definitely no longer works (I have also tested with 5.1.4). #!/bin/sh fn() { echo a >&3 } b=`fn 3>&1 1>&4 4>&-`