[PATCH] exec: free args on failed exec

The comment describing why this wasn't done has been there since the start of the repo's history and AFAICT it is not accurate anymore, as shell_execve only calls realloc when it's going to longjmp rather than return. Fixes leak in bash -O execfail -c 'exec /; :' --- builtins/exec.def | 4

[PATCH] expand_word_internal: fix leak with W_NOSPLIT2

Free temporary list allocated when exapnding `$@' in bash -c 'IFS=:; : ${_+$@}' _ X --- subst.c | 1 + 1 file changed, 1 insertion(+) diff --git a/subst.c b/subst.c index 3faa4068..c56d2434 100644 --- a/subst.c +++ b/subst.c @@ -12144,6 +12144,7 @@ finished_with_string:

[PATCH] coproc: do not leak name

When a named coproc is created, the name string and associated WORD_DESC are leaked. --- parse.y | 2 ++ 1 file changed, 2 insertions(+) diff --git a/parse.y b/parse.y index d39d6737..fe5038be 100644 --- a/parse.y +++ b/parse.y @@ -1103,6 +1103,7 @@ coproc: COPROC shell_command

[PATCH] cond expr: cleanup on errors

Two minor leak fixes for conditional command error conditions: If a WORD token is read when COND_AND, COND_OR, COND_END, or a binary operator are expected, the allocated WORD_DESC is leaked. If a conditional command has a syntax error, the allocated COMMAND is leaked. --- parse.y | 14

Re: read reads from stale buffer after interrupt

On 5/31/24 11:57 AM, Oğuz wrote: On Friday, May 31, 2024, Chet Ramey > wrote: Thanks for the report. Since this occurs when read(2) returns a partial buffer on an interrupt, I think we can handle it in read_builtin(). Okay, handle how though? Leave the file

Re: read reads from stale buffer after interrupt

On Friday, May 31, 2024, Chet Ramey wrote: > > Thanks for the report. Since this occurs when read(2) returns a partial > buffer on an interrupt, I think we can handle it in read_builtin(). > Okay, handle how though? Leave the file offset at the last byte read before the interrupt or where the

Re: [PATCH] bind_assoc_variable: free key if cannot assign

On 5/30/24 5:30 PM, Grisha Levit wrote: Avoid leaking expansion of `x' in `declare -Ar A; A[x]=' Thanks for the report. I think a more appropriate place to fix this is assign_array_element_internal(), since that's where the key is allocated. Chet -- ``The lyf so short, the craft so long to

Re: read reads from stale buffer after interrupt

On 5/28/24 1:53 AM, Oğuz wrote: See: $ while read; do :; done Thanks for the report. Since this occurs when read(2) returns a partial buffer on an interrupt, I think we can handle it in read_builtin(). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

[PATCH] bind_assoc_variable: free key if cannot assign

Avoid leaking expansion of `x' in `declare -Ar A; A[x]=' --- arrayfunc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arrayfunc.c b/arrayfunc.c index e85ba6e5..aaa1963c 100644 --- a/arrayfunc.c +++ b/arrayfunc.c @@ -302,6 +302,7 @@ bind_assoc_variable (SHELL_VAR *entry, const char *name,

Re: [PATCH] read: free ifs_chars

On 5/29/24 3:31 PM, Grisha Levit wrote: Avoid leaking ifs_chars on more return paths. 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.edu

Re: [PATCH] readstr: do not clear undo list

On 5/27/24 7:56 PM, Grisha Levit wrote: The undo command fails if invoked via execute-named-command on a line from the history list: $ bash --norc -in <<< $'A\n\cPB\c_C' bash-5.3$ A bash-5.3$ AC $ bash --norc -in <<< $'A\n\cPB\exundo\nC' bash-5.3$ A bash-5.3$ ABC

Re: Bash has a stack overflow vulnerability

On 5/30/24 12:53 AM, B_M wrote: Hello, I have discovered a severe heap overflow vulnerability in Bash, which exists in both the latest and older versions. Attackers can craft payloads to elevate privileges or execute malicious code. Should I directly submit it to the CVE website, or should I

Bash has a stack overflow vulnerability

Hello, I have discovered a severe heap overflow vulnerability in Bash, which exists in both the latest and older versions. Attackers can craft payloads to elevate privileges or execute malicious code. Should I directly submit it to the CVE website, or should I send it to you? If I send it to you,

[PATCH] read: free ifs_chars

Avoid leaking ifs_chars on more return paths. --- builtins/read.def | 16 1 file changed, 16 insertions(+) diff --git a/builtins/read.def b/builtins/read.def index 37328efc..69a1ef4c 100644 --- a/builtins/read.def +++ b/builtins/read.def @@ -635,6 +635,8 @@ read_builtin

Re: compute_lcd_of_matches w/ mismatched upper/lowercase byte counts

On 5/24/24 4:02 AM, Grisha Levit wrote: This requires case-insensitive completion of two+ words where the the prefix in a word contains the single-byte lowercase form of the multi- byte character occuring in the same position in an earlier word. Thanks for the report. Common prefixes of

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

"The 'printf' in shells is different than the 'printf' specified by ISO C/POSIX. The documentation for the bash built-in can be found here: $ info '(bash)Bash Builtins' The 'printf' provided in your C library should be found in man page section 3. Your system probably comes with a program

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

>I guess it could be more explicit Yes, that is essentially what I was asking for. There are several standards for printf, and it was ambiguous which one was being referred to. There's the C standards, the POSIX standards, and the Single Unix Specifications. I didn't know which one was being

Re: yet another $(case ... parse bug

On 5/24/24 1:43 AM, Oğuz wrote: While you're at it take a look at this too: true; for (( ; $? == 0; ${ ! break;} )); do uname; done The arithmetic for command should probably check for breaking after it evaluates the loop test. You have to admit this is not something people are going to write

Re: yet another $(case ... parse bug

On 5/23/24 1:19 PM, Oğuz wrote: See: $ bash -c 'for (( $(case x in x) esac);; )); do :; done' bash: -c: line 1: syntax error: `;' unexpected bash: -c: line 1: syntax error: `(( $(case x in x) ;; esac);; ))' Thanks for the report. This should be a pretty easy fix; just use

Re: segmentation fault after interrupting function that uses "time"

On 5/23/24 9:09 PM, Grisha Levit wrote: On Thu, May 23, 2024 at 3:55 PM Chet Ramey wrote: On 5/23/24 7:43 AM, Michael Maurer wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Calling a function that itself uses the keyword "time" to call another function

read reads from stale buffer after interrupt

See: $ while read; do :; done

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

POSIX Issue 8 will require that this feature is supported, see https://www.austingroupbugs.net/view.php?id=1592 Perhaps a future version of Bash will have it. -- Oğuz

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

On Mon, May 27, 2024, at 8:58 PM, porterleete wrote: > The man page for printf says that for integer m, %m$ lets you > specify which argument that the conversion specification will use. > Similarly, using *m$ instead of * in a conversion specification lets > you specify which argument the * will

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

porterleete writes: > Fix: > Either update the documentation of what printf in bash actually does. > If printf is using a standard for printf other than "what the biggest > C compilers currently do", document which standard it's using or > update it to the newest standard used by gcc and clang.

printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux portercomp3 6.9.1 #1-NixOS SMP PREEMPT_DYNAMIC Fri May 17 10:18:09 UTC 2024 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash

[PATCH] readstr: do not clear undo list

The undo command fails if invoked via execute-named-command on a line from the history list: $ bash --norc -in <<< $'A\n\cPB\c_C' bash-5.3$ A bash-5.3$ AC $ bash --norc -in <<< $'A\n\cPB\exundo\nC' bash-5.3$ A bash-5.3$ ABC AFAICT the rl_maybe_replace_line in

Re: Incorrect string length check

On 5/23/24 9:55 PM, Collin Funk wrote: Hi Chet, In this commit in the devel branch: commit 03c8c43b79177fa678714893e9f05b1c517592c0 Author: Chet Ramey Date: Fri Apr 5 09:03:52 2024 -0400 man page typesetting updates for compatibilityand layout issues I think there was a typo in

Re: [PATCH] rl_change_case: skip over invalid mbchars

On 5/23/24 3:25 PM, Grisha Levit wrote: Then we again interpret \xC0 as if it were \u00C0: rl_change_case(count=-1, op=2) at text.c:1514:20 1513 if (MB_INVALIDCH (m)) -> 1514 wc = (WCHAR_T)rl_line_buffer[start]; (wchar_t) wc = L'À' Sometimes the

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月25日(土) 8:45 Lawrence Velázquez : > On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote: > > 2024年5月24日(金) 19:18 Martin D Kealey : > >> On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: > >>> However, I personally do not think the FPATH mechanism is useful > >>> because a file can only

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote: > 2024年5月24日(金) 19:18 Martin D Kealey : >> On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: >>> However, I personally do not think the FPATH mechanism is useful >>> because a file can only contain one function per file. Significantly >>>

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月24日(金) 19:18 Martin D Kealey : > On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: >> 2024年5月21日(火) 14:56 Phi Debian : >> > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't >> > know if that would be good enough for the initial purpose. >> >> There are already

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: > 2024年5月21日(火) 14:56 Phi Debian : > > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > > know if that would be good enough for the initial purpose. > > There are already shell-function implementations at >

compute_lcd_of_matches w/ mismatched upper/lowercase byte counts

This requires case-insensitive completion of two+ words where the the prefix in a word contains the single-byte lowercase form of the multi- byte character occuring in the same position in an earlier word. The words here start consist of one of the following followed by `-': U+212A KELVIN

Re: yet another $(case ... parse bug

While you're at it take a look at this too: true; for (( ; $? == 0; ${ ! break;} )); do uname; done Once you run this command bash gets stuck in a state where it prints the prompt string and reads commands but doesn't execute anything. If you press Ctrl+C it returns to normal. Oğuz

Incorrect string length check

Hi Chet, In this commit in the devel branch: commit 03c8c43b79177fa678714893e9f05b1c517592c0 Author: Chet Ramey Date: Fri Apr 5 09:03:52 2024 -0400 man page typesetting updates for compatibilityand layout issues I think there was a typo in execute_cmd.c: diff --git a/execute_cmd.c

Re: segmentation fault after interrupting function that uses "time"

On Thu, May 23, 2024 at 3:55 PM Chet Ramey wrote: > > On 5/23/24 7:43 AM, Michael Maurer wrote: > > > Bash Version: 5.2 > > Patch Level: 15 > > Release Status: release > > > > Description: > > Calling a function that itself uses the keyword "time" to call > > another function that performs

Re: [PATCH] rl_change_case: skip over invalid mbchars

On Thu, May 23, 2024 at 4:11 PM Chet Ramey wrote: > > On 5/23/24 3:25 PM, Grisha Levit wrote: > > On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote: > >> > >> On 5/21/24 2:42 PM, Grisha Levit wrote: > >>> Avoid using (size_t)-1 as an offset. > >> > >> I can't reproduce this on macOS. Where is

Re: [PATCH] rl_change_case: skip over invalid mbchars

On 5/23/24 3:25 PM, Grisha Levit wrote: On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote: On 5/21/24 2:42 PM, Grisha Levit wrote: Avoid using (size_t)-1 as an offset. I can't reproduce this on macOS. Where is the code that's using -1 as an offset? The loop in rl_change_case does the

Re: segmentation fault after interrupting function that uses "time"

On 5/23/24 7:43 AM, Michael Maurer wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Calling a function that itself uses the keyword "time" to call another function that performs a long task, and then interrupting with Ctrl+C before it is complete, causes

Re: [PATCH] rl_change_case: skip over invalid mbchars

On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote: > > On 5/21/24 2:42 PM, Grisha Levit wrote: > > Avoid using (size_t)-1 as an offset. > > I can't reproduce this on macOS. Where is the code that's using -1 as an > offset? The loop in rl_change_case does the following:

yet another $(case ... parse bug

See: $ bash -c 'for (( $(case x in x) esac);; )); do :; done' bash: -c: line 1: syntax error: `;' unexpected bash: -c: line 1: syntax error: `(( $(case x in x) ;; esac);; ))' This is reproducible on 5.3 alpha too. Oğuz

Re: [PATCH] rl_change_case: skip over invalid mbchars

On 5/21/24 2:42 PM, Grisha Levit wrote: Avoid using (size_t)-1 as an offset. I can't reproduce this on macOS. Where is the code that's using -1 as an offset? Also, not sure it makes sense to change the case of an invalid byte cast to (wchar_t). Bash and readline are pretty consistent about

Re: sh vs. bash -xc 'a=b c=$a'

if u var=value command ; the var's only for cmd and disappears afterwards if u var=val ; cmd ; its not for cmd , excepts exported and is set after cmd , usual behav old rule On Thu, May 23, 2024, 3:34 PM Robert Elz wrote: > Date:Thu, 23 May 2024 09:04:48 -0400 > From:

Re: sh vs. bash -xc 'a=b c=$a'

Date:Thu, 23 May 2024 09:04:48 -0400 From:Chet Ramey Message-ID: | The bash output clearly tells you the | order of operations, which is the whole purpose of -x. But it can be horribly misleading. Consider what bash does with this similar case (I used 5.3a1

Re: sh vs. bash -xc 'a=b c=$a'

On 5/22/24 10:57 PM, Oğuz wrote: And some Bourne shells expand command substitutions first $ (exit 5) $ x=$? y=`exit 10` $ echo $x 10 It's worse than that. The v7 sh performed assignments right to left. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

Re: sh vs. bash -xc 'a=b c=$a'

On 5/22/24 6:56 PM, Dan Jacobson wrote: It seems these should both make one line "+ a=b c=b" output, for s in sh bash do $s -xc 'a=b c=$a' done I mean they give the same results, but bash splits it into two lines, so the user reading the bash -x output cannot tell if one (correct) or two

segmentation fault after interrupting function that uses "time"

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux nb 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)

Re: sh vs. bash -xc 'a=b c=$a'

Date:Thu, 23 May 2024 05:57:05 +0300 From:=?UTF-8?B?T8SfdXo=?= Message-ID: | On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote: | > Only to note that this is not portable. | Nor will NetBSD sh. That's right, and this is expressly unspecified in POSIX.

Re: sh vs. bash -xc 'a=b c=$a'

On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote: > Only to note that this is not portable. > The FreeBSD shell will not assign "b" to "c" for this one! Nor will NetBSD sh. This lets you swap values of two variables without using a third $ x=1 y=2 $ x=$y y=$x $ echo $x $y 2 1 And some

Re: sh vs. bash -xc 'a=b c=$a'

Greg Wooledge wrote in : |On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: |> It seems these should both make one line "+ a=b c=b" output, |> |> for s in sh bash |> do $s -xc 'a=b c=$a' Only to note that this is not portable. The FreeBSD shell will not assign "b" to "c" for

Re: sh vs. bash -xc 'a=b c=$a'

On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: > It seems these should both make one line "+ a=b c=b" output, > > for s in sh bash > do $s -xc 'a=b c=$a' > done > > I mean they give the same results, but bash splits it into > two lines, so the user reading the bash -x output

sh vs. bash -xc 'a=b c=$a'

It seems these should both make one line "+ a=b c=b" output, for s in sh bash do $s -xc 'a=b c=$a' done I mean they give the same results, but bash splits it into two lines, so the user reading the bash -x output cannot tell if one (correct) or two (incorrect) lines were used. They can tell with

Re: [PATCH] spell-correct-word: avoid inf loop with neg arg

On 5/21/24 10:41 PM, Grisha Levit wrote: bash --norc -in <<< $'A \e-\cXs' I think I'd rather make negative counts work in the opposite direction. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech,

Re: [PATCH] dynamic-complete-history: avoid null ptr qsort UB

On 5/21/24 11:58 PM, Grisha Levit wrote: $ HISTFILE= bash --norc -in <<< $'#\n#\e\t' bashline.c:3720:16: runtime error: null pointer passed as argument 1, which is declared to never be null /usr/include/stdlib.h:971:30: note: nonnull attribute specified here SUMMARY: UndefinedBehaviorSanitizer:

Re: printf -u "$fd"?

On 5/22/24 12:32 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 3:06 PM Chet Ramey wrote: On 5/21/24 11:14 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and

Re: [PATCH] bashline: small leaks

On 5/21/24 11:34 AM, Grisha Levit wrote: - free directory_part when completing command words like `~/bin/' - free contents of matches when completing command words in old-style command substitutions Thanks for the report and patch. -- ``The lyf so short, the craft so long to lerne.'' -

Re: [PATCH] execute-named-command: fix small leaks

On 5/21/24 11:32 AM, Grisha Levit wrote: - free command if it is the empty string - free command before calling bound function, in case bound function does not return, like rl_abort Thanks for the report. I don't want to ring the bell if the command is the empty string, so I did this

Re: printf -u "$fd"?

On Wed, May 22, 2024 at 12:32 AM Zachary Santer wrote: > > In my Rocky Linux 9.1 VM: > $ bash --version > GNU bash, version 5.1.8(1)-release [...] > $ exec {fd_A}> >( cat > file_A.txt ) > $ exec {fd_B}> >( cat > file_B.txt ) > $ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}" > words >

Re: printf -u "$fd"?

2024年5月22日(水) 0:15 Zachary Santer : > Additionally, I was hoping the discussion of having a way to make fds > not CLOEXEC without a loadable builtin[3][4] would get some more > attention. I haven't followed the discussion in the original thread for multiple coprocs, but you can remove CLOEXEC

Re: printf -u "$fd"?

On Tue, May 21, 2024 at 3:06 PM Chet Ramey wrote: > > On 5/21/24 11:14 AM, Zachary Santer wrote: > > On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: > >> > >> On 5/21/24 6:17 AM, Zachary Santer wrote: > >> > >>> I was wondering what the relationship between the devel and master > >>> branches

[PATCH] dynamic-complete-history: avoid null ptr qsort UB

$ HISTFILE= bash --norc -in <<< $'#\n#\e\t' bashline.c:3720:16: runtime error: null pointer passed as argument 1, which is declared to never be null /usr/include/stdlib.h:971:30: note: nonnull attribute specified here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bashline.c:3720:16 ---

[PATCH] spell-correct-word: avoid inf loop with neg arg

bash --norc -in <<< $'A \e-\cXs' --- bashline.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bashline.c b/bashline.c index 528f56e0..0a4e280e 100644 --- a/bashline.c +++ b/bashline.c @@ -1336,6 +1336,9 @@ bash_spell_correct_shellword (int count, int key) int wbeg, wend; char

[PATCH] spell-correct-word: fix small leak

Avoid leak when spell-correcting an empty line. --- bashline.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/bashline.c b/bashline.c index 525d065a..528f56e0 100644 --- a/bashline.c +++ b/bashline.c @@ -1348,7 +1348,10 @@ bash_spell_correct_shellword (int count, int key)

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, 21 May 2024 at 03:44, Chet Ramey wrote: > On 5/17/24 1:15 PM, Robert Elz wrote: > > >| If `nosort' means no sorting, there is no imposed ordering, and > ascending > >| and descending are meaningless. > > > > Sure, but directory order, and reverse directory order aren't (and

Re: printf -u "$fd"?

On 5/21/24 11:14 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and master branches was. No mystery: the devel branch captures ongoing development, gets the

[PATCH] rl_change_case: skip over invalid mbchars

Avoid using (size_t)-1 as an offset. Also, not sure it makes sense to change the case of an invalid byte cast to (wchar_t). $ bash --norc -in <<< $'\300\e-1\eL' lib/readline/text.c:1544:26: runtime error: addition of unsigned offset to 0x51100680 overflowed to 0x5110067f ERROR:

[PATCH] bashline: small leaks

- free directory_part when completing command words like `~/bin/' - free contents of matches when completing command words in old-style command substitutions --- bashline.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/bashline.c b/bashline.c index b638e001..525d065a

[PATCH] execute-named-command: fix small leaks

- free command if it is the empty string - free command before calling bound function, in case bound function does not return, like rl_abort --- lib/readline/text.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/readline/text.c b/lib/readline/text.c index

Re: printf -u "$fd"?

On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: > > On 5/21/24 6:17 AM, Zachary Santer wrote: > > > I was wondering what the relationship between the devel and master > > branches was. > > No mystery: the devel branch captures ongoing development, gets the latest > bug fixes, and is where new

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/21/24 1:55 AM, Phi Debian wrote: The idea started before the current discussion as a way to avoid overloading PATH in the source builtin: https://lists.gnu.org/archive/html/help-bash/2024-04/msg00022.html Some thought 'source' was a good candidate for this, except that source is a

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 1:17 PM Koichi Murase wrote: > There are already shell-function implementations at > /examples/functions/autoload* in the Bash source. They reference FPATH > to load functions, though one needs to call `autoload' for each > function in advance (by e.g. `autoload

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/21/24 12:49 AM, konsolebox wrote: `Properly' is clearly in the eye of the beholder. I'm sorry if I have to sound assertive on this one but I thoroughly thought about these things years ago and made a framework that works on a multitude of shells, allows both simple and pattern-based

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 1:15 PM Greg Wooledge wrote: > On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira > wrote: > > > the schizophrenic nature of the feature > > > > First the feature was "irritating" ... Now it's "schizophrenic" ? > > I must be mentally ill for trying

Re: printf -u "$fd"?

On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and master branches was. No mystery: the devel branch captures ongoing development, gets the latest bug fixes, and is where new features appear. The master branch is for stable releases. I saw

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024, 13:18 Koichi Murase wrote: > 2024年5月21日(火) 14:56 Phi Debian : > > Apparently konsolebox wrote a package manager, and survived the source > 'as > > is', yet he still advocate for 'enhancement'. I do have a package manager > > too, and survived source 'as is' and don't

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月21日(火) 14:56 Phi Debian : > Apparently konsolebox wrote a package manager, and survived the source 'as > is', yet he still advocate for 'enhancement'. I do have a package manager > too, and survived source 'as is' and don't require any enhancement. I'm not sure if it is the case for

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira wrote: > > the schizophrenic nature of the feature > > First the feature was "irritating" ... Now it's "schizophrenic" ? > I must be mentally ill for trying to contribute this? > > Yeah, I'm done. I don't think

Re: printf -u "$fd"?

On Mon, May 20, 2024 at 3:03 PM Chet Ramey wrote: > > On 5/17/24 10:53 PM, Zachary Santer wrote: > > > So here's another tangent, but has it been considered to add an option > > to the printf builtin to print to a given file descriptor, rather than > > stdout? If printing to a number of different

Re: [PATCH v2 5/8] builtins/source: parse the -i option

> the schizophrenic nature of the feature First the feature was "irritating" ... Now it's "schizophrenic" ? I must be mentally ill for trying to contribute this? Yeah, I'm done.

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 7:54 PM Greg Wooledge wrote: > On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote: > > On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira > wrote: > > > > PATH=${BASH_SEARCH_PATH-$PATH} . file > > > > without the need to add any

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 4:10 AM Chet Ramey wrote: > > On 5/20/24 3:39 AM, konsolebox wrote: > > > It's rare for a topic about adding an import/include function to get > > so much attention like this I think it's time Bash takes the > > opportunity to implement it and hopefully properly. > >

[PATCH] spell.c: uninitialized value in mindist

./bash --norc -in <<<$'XX\cXs' bash-5.3$ XX==34016==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xaafbbb80 in mindist /home/vm/src/bash/local/lib/sh/spell.c:138:22 #1 0xaafbb468 in spname /home/vm/src/bash/local/lib/sh/spell.c:90:11 #2 0xaafbbe78 in dirspell

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月17日(金) 4:36 Greg Wooledge : > On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote: > > On 5/15/24 11:31 AM, Koichi Murase wrote: > > > Maybe it was not clear to use `source name' and `source -i name' to > > > describe the idea. I meant I assumed the search domain being > > > > > > *

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/20/24 4:17 PM, Matheus Afonso Martins Moreira wrote: And yet people are so opposed to the option that they want ridiculous restrictions like `you can never alias source="source -i"'. Yeah. I already feel like I'm insane for even suggesting it. People feel strongly, it seems. More

Re: [PATCH v2 5/8] builtins/source: parse the -i option

> And yet people are so opposed to the option that they want ridiculous > restrictions like `you can never alias source="source -i"'. Yeah. I already feel like I'm insane for even suggesting it. > Because other people don't see the issue the same way you do, > and have their own way of doing

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/20/24 3:39 AM, konsolebox wrote: It's rare for a topic about adding an import/include function to get so much attention like this I think it's time Bash takes the opportunity to implement it and hopefully properly. `Properly' is clearly in the eye of the beholder. -- ``The lyf so short,

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/19/24 6:31 AM, Matheus Afonso Martins Moreira wrote: There is absolutely no doubt that this is useful. Not long after I sent the patches, a list of about a dozen projects implementing module loading and management in bash was posted. Clearly this is something people want. I think the

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/19/24 4:58 AM, Matheus Afonso Martins Moreira wrote: Bash has the command builtin which can be used to ensure a real utility is executed instead of an alias or function. It also works for builtins such as source. I could also propose a new flag for it that restricts its operation to

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/18/24 7:00 PM, Matheus Afonso Martins Moreira wrote: The issue is that what you want, and what I want, and what konsolebox wants (and everyone else) are all slighty different. The option solution which I proposed is not really in opposition to anything that anyone else wants. It will not

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/18/24 11:17 AM, Phi Debian wrote: an enforcement that no alias source='source -i' could ever be possible. This seems ridiculous. There should never be a prohibition against a user doing something that is not dangerous. All this is because one writing a 'main' script (#!/bin/bash),

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/18/24 8:57 PM, Robert Elz wrote: Date:Sat, 18 May 2024 23:00:41 + From:Matheus Afonso Martins Moreira Message-ID: | If you resolve the path, you're just reinventing the source builtin. Nonsense, the real work of the source ('.' really) utility is

Re: printf -u "$fd"?

On 5/17/24 10:53 PM, Zachary Santer wrote: So here's another tangent, but has it been considered to add an option to the printf builtin to print to a given file descriptor, rather than stdout? If printing to a number of different file descriptors in succession, such an option would appear to

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/17/24 11:40 AM, Robert Elz wrote: Now of course, everyone is going to say "too difficult to do that all the time", and they'd be right. So the one extra feature would be that if used without the "file" arg (which is normally mandatory), as in . -p path-like-value it would set the

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On 5/20/24 1:43 PM, Andreas Kähäri wrote: Or even PATH=${BASH_SEARCH_PATH-$PATH} . file without the need to add any options to . or to source. Yeah, that's where we started. https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00038.html -- ``The lyf so short, the craft so

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 01:54:20PM -0400, Greg Wooledge wrote: > On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote: > > On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira > > wrote: > > > >> Why not add a -p option to '.' to specify the path to search. > > > >>

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote: > On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira > wrote: > > >> Why not add a -p option to '.' to specify the path to search. > > >> That is > > >>. -p "${BASH_SEARCH_PATH-${PATH}}" file > > >> would

Re: [PATCH v2 5/8] builtins/source: parse the -i option

> Or even > > PATH=${BASH_SEARCH_PATH-$PATH} . file > > without the need to add any options to . or to source. If you do that, you'll interfere with command search in the sourced file. They will not be able to find the programs that would normally be in the PATH if the variable is overridden

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira wrote: > >> Why not add a -p option to '.' to specify the path to search. > >> That is > >>. -p "${BASH_SEARCH_PATH-${PATH}}" file > >> would work if someone decided to use the > >> BASH_SOURCE_PATH var name to store the

Re: [PATCH v2 5/8] builtins/source: parse the -i option

>> Why not add a -p option to '.' to specify the path to search. >> That is >>. -p "${BASH_SEARCH_PATH-${PATH}}" file >> would work if someone decided to use the >> BASH_SOURCE_PATH var name to store the path to use >> (defaulting to $PATH if that one isn't set). > Believe it or not, I had

Re: [PATCH] globsort: handle int overflow in cmp functions

On Mai 17 2024, Grisha Levit wrote: > The current cmp implementation for size and blocks subtracts the two > values and returns the difference as an int. This subtraction can > overflow, and the returned int can end up having the wrong sign. In the case of globsort_sizecmp, since off_t is wider

  1   2   3   4   5   6   7   8   9   10   >