Re: history-search-backward clobbers history

On 7/1/24 10:35 AM, Andreas Schwab wrote: The wrong thing is that the history contains commands that were never executed: echo 13456 and echo 21234. This is the result of changes to non-incremental search to make it behave more consistently like incremental search, which has always behaved like

Re: [PATCH] libsh: Omit strtoimax if HAVE_STRTOIMAX

On 7/2/24 11:21 PM, Ismael Luceno wrote: Signed-off-by: Ismael Luceno --- lib/sh/strtoimax.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) This isn't right; strtoimax.o is only added to OBJECTS if libc doesn't provide it. There is a bug in the autoconf test for strtoimax tha

Re: «run_pending_traps: bad value in trap_list» when `jobs` is run a trap

On 7/1/24 4:45 PM, Gioele Barabucci wrote: Hi, the following script (reduced from )     #!/bin/bash     childfinished () { echo "jobs: $(jobs)"; }     trap childfinished SIGCHLD     sleep 1 &     wait causes bash 5.2.21 to output     ./par.sh: line 2: war

Re: proposed BASH_SOURCE_PATH

On 6/26/24 7:18 PM, Martin D Kealey wrote: I've found some existing code that will break if words in ${BASH_SOURCE[@]} don't match the filepath given to '.' or 'source':   [[ ${BASH_ARGV[0]} = "${BASH_SOURCE[0]}" ]] which is part of a test to determine whether any args were provided after "sou

Re: proposed BASH_SOURCE_PATH

On 6/26/24 8:17 AM, Martin D Kealey wrote: On Wed, 26 Jun 2024, 03:14 Chet Ramey, > wrote: On 6/19/24 6:12 PM, konsolebox wrote: > Alternatively, have BASH_SOURCE always produce real physical paths > either by default or through a shopt. This is

Re: waiting for process substitutions

On 6/29/24 8:47 AM, Zachary Santer wrote: From the manual: wait [-fn] [-p varname] [id ...] Wait for each specified child process and return its termination status. Each id may be a process ID or a job specification; if a job spec is given, all processes in that job's pipeline are waited for. If

Re: proposed BASH_SOURCE_PATH

On 6/26/24 7:18 PM, Martin D Kealey wrote: But unfortunately in this case, BASH_ARGC[0] is 1 rather than 0,, and the filename provided to "source" (now ${BASH_SOURCE[0]}) is prepended to BASH_ARGV. Because that's the state of this call frame, and that's what the bash debugger -- why these va

Re: «run_pending_traps: bad value in trap_list» when `jobs` is run a trap

On 03/07/24 15:33, Chet Ramey wrote: On 7/1/24 4:45 PM, Gioele Barabucci wrote: the following script (reduced from ) #!/bin/bash childfinished () { echo "jobs: $(jobs)"; } trap childfinished SIGCHLD sleep 1 & wait causes bash 5.2.21 to o

Re: «run_pending_traps: bad value in trap_list» when `jobs` is run a trap

On 7/3/24 2:14 PM, Gioele Barabucci wrote: On 03/07/24 15:33, Chet Ramey wrote: On 7/1/24 4:45 PM, Gioele Barabucci wrote: the following script (reduced from ) #!/bin/bash childfinished () { echo "jobs: $(jobs)"; } trap childfinished SIGCHLD

Re: proposed BASH_SOURCE_PATH

On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey wrote: > > On 6/26/24 5:59 AM, konsolebox wrote: > > On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote: > >> > >> On 6/19/24 6:12 PM, konsolebox wrote: > >> > >>> Alternatively, have BASH_SOURCE always produce real physical paths > >>> either by default

Re: [PATCH] libsh: Omit strtoimax if HAVE_STRTOIMAX

On 03/Jul/2024 09:12, Chet Ramey wrote: > On 7/2/24 11:21 PM, Ismael Luceno wrote: > > Signed-off-by: Ismael Luceno > > --- > > lib/sh/strtoimax.c | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > This isn't right; strtoimax.o is only added to OBJECTS if libc doesn't > prov

Re: proposed BASH_SOURCE_PATH

On 7/3/24 2:37 PM, konsolebox wrote: On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey wrote: On 6/26/24 5:59 AM, konsolebox wrote: On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote: On 6/19/24 6:12 PM, konsolebox wrote: Alternatively, have BASH_SOURCE always produce real physical paths either

Re: [PATCH] libsh: Omit strtoimax if HAVE_STRTOIMAX

On 7/3/24 2:51 PM, Ismael Luceno wrote: On 03/Jul/2024 09:12, Chet Ramey wrote: On 7/2/24 11:21 PM, Ismael Luceno wrote: Signed-off-by: Ismael Luceno --- lib/sh/strtoimax.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) This isn't right; strtoimax.o is only added to OBJEC

Re: proposed BASH_SOURCE_PATH

On Thu, Jul 4, 2024 at 2:54 AM Chet Ramey wrote: > So your answer is "yes." Is there anything to be gained by leaving the > pathname to source/. unchanged and just storing the full pathname of the > script file argument? > > I'm looking for input from people who write shell frameworks here. The on

printf fails in version 5.2.026-3

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-p

Re: proposed BASH_SOURCE_PATH

is this all about adding full path ? to sourcr / . ? for this may add one varname , like BASH_SOURCE_FULL it seems to me , using BASH_SOURCE , if it doesnt start with / , prefix $PWD , .. else its already i say about nee var cause it'd be a derivate of , like , BASH_SOURCE warm greets .. On Wed

Re: printf fails in version 5.2.026-3

On Wed, Jul 03, 2024 at 22:24:43 +0200, szige...@delg0.elte.hu wrote: > Description: > printf works in version 5.2.026-2, fails in version 5.2.026-3 What exactly are these version numbers? Are they packages from some Linux distrbution? > Repeat-By: > contents of tmp.sh begins ---

Re: printf fails in version 5.2.026-3

szige...@delg0.elte.hu writes: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt > -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security > -fs

Re: waiting for process substitutions

On Thu, 4 Jul 2024, 03:21 Chet Ramey, wrote: > Why not just wait for all process substitutions? > Process substitutions [...] are not expected to survive their read/write > file descriptors becoming invalid. You shouldn't need to `wait' for them; > they're not true asynchronous processes. > A

Re: waiting for process substitutions

On Wed, Jul 3, 2024 at 11:21 AM Chet Ramey wrote: > > Process substitutions are word expansions, with a scope of a single > command, and are not expected to survive their read/write file descriptors > becoming invalid. You shouldn't need to `wait' for them; they're not > true asynchronous processe

[@]@A weird behaviour when IFS does not contain space

Hello. Normally, ${foo[@]@A} expands to multiple values, that are the arguments to run a declare command that sets foo to the current value/attributes. bash-5.2$ a=( abc xyz 123 ); declare -pa result=("${a[@]@A}") declare -a result=([0]="declare" [1]="-a" [2]="a=([0]=\"abc\" [1]=\"xyz\"