Re: $* within a here-document puts space instead of the first IFS char.

On Fri, Feb 16, 2024 at 9:02 PM Damien ISSANCHOU wrote: > When expanding $* within a here-document, bash puts a space between > each positional parameters while I would expect it to put the first > character of the IFS variable (if it contains at least one character) as > per POSIX.1-2017.

Re: Bash 5.1: Make shell_script_filename available to startup files

On Fri, Feb 16, 2024, 16:17 Marc Aurèle La France wrote: > > On Mon, 2021-Feb-01, Marc Aurèle La France wrote: > > > 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

Re: $* within a here-document puts space instead of the first IFS char.

Date:Sat, 17 Feb 2024 01:41:11 +0100 From:Damien ISSANCHOU Message-ID: | Even though the online Bash Reference manual only explicitly states | the POSIX behaviour when the expansion of the special parameter * occurs | within double-quotes, it seems that it

Re: Bash 5.1: Make shell_script_filename available to startup files

On Fri, 2024-Feb-16, Zachary Santer wrote: On Fri, Feb 16, 2024, Marc Aurèle La France wrote: On Mon, 2021-Feb-01, Marc Aurèle La France wrote: Currently, only the script's arguments are passed as positional parameters. For compatibility reasons, $0 cannot be used to also pass the script's

Re: [PATCH] use unlocked stdio functions

After this change, `make -C examples/loadables others` fails building necho.o with: use of undeclared identifier 'fflush_unlocked' I checked other object files to make sure the expected symbols are used and they were, except for the loadable pushd. Also added the dependency where needed in

$* within a here-document puts space instead of the first IFS char.

From: Damien Issanchou To: bug-bash@gnu.org Subject: $* within a here-document puts space instead of the first IFS char. Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux AsWhite 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1

Re: Bash 5.1: Make shell_script_filename available to startup files

On Fri, Feb 16, 2024 at 4:17 PM Marc Aurèle La France wrote: > On Mon, 2021-Feb-01, Marc Aurèle La France wrote: > > > 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

Re: Bash 5.1: Make shell_script_filename available to startup files

On Mon, 2021-Feb-01, Marc Aurèle La France wrote: 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. --- bash-5.1/doc/bash.1 +++

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

On 2/16/24 12:14 PM, Grisha Levit wrote: Let's say we take the approach of restricting attribute changes on readonly variables to export/trace/local. Should it be an error to attempt to set other attributes (it already is with nameref), or should declare silently ignore it? I think an error

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

On Fri, Feb 16, 2024 at 11:32 AM Chet Ramey wrote: > > On 2/13/24 12:41 PM, Grisha Levit wrote: > > On Wed, Jan 31, 2024, 14:10 Chet Ramey > > wrote: > > > > Well, is this a "my arm hurts when I do this" problem, or should bash > > restrict the types of

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

On 2/13/24 12:41 PM, Grisha Levit wrote: On Wed, Jan 31, 2024, 14:10 Chet Ramey > wrote: Well, is this a "my arm hurts when I do this" problem, or should bash restrict the types of attributes that can be set on readonly variables? For the attributes that