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 opti

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. > > `Prope

[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 /hom

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 > > > > > > * B

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 strongl

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 thin

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 poin

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 builtin

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 b

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), sourc

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 hav

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 d

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 lon

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. > > > >> T

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 wor

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 p

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 p

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 tho

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 t

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

On 5/17/24 9:47 PM, Martin D Kealey wrote: On Fri, 17 May 2024 at 04:18, Chet Ramey > wrote: On 5/16/24 11:54 AM, G. Branden Robinson wrote: > At 2024-05-16T11:36:50-0400, Chet Ramey wrote: >> On 5/15/24 6:27 PM, Robert Elz wrote: >>> and any att

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

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 that's just a difference between the order in which you create the list as

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

On 5/17/24 11:40 AM, Robert Elz wrote: Date:Fri, 17 May 2024 10:09:06 -0400 From:Chet Ramey Message-ID: | If you don't want `.' to search $PATH, turn off the `sourcepath' shell | option. That part I assumed was already taken care of (that is, would be) ju

Re: [PATCH] bracketed paste unterminated buffer

On 5/20/24 10:56 AM, Grisha Levit wrote: On Mon, May 20, 2024, 10:52 Chet Ramey > wrote: On 5/20/24 10:42 AM, Grisha Levit wrote: > If bracketed paste input terminates prior to the paste end sequence, How would this happen? The terminal emulator (or w

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

> Bash would not set this to any value, since it doesn't install anything > that would use it. To set it is to apply policy. What I meant to say is that I as the user can set it globally on my bash initialization script so that I can always make use of the new feature. If the act of setting it cha

Re: [PATCH] bracketed paste unterminated buffer

On Mon, May 20, 2024, 10:52 Chet Ramey wrote: > On 5/20/24 10:42 AM, Grisha Levit wrote: > > If bracketed paste input terminates prior to the paste end sequence, > > How would this happen? The terminal emulator (or whatever) performing > the paste guarantees it. > Maybe over a serial connection

Re: [PATCH] bracketed paste unterminated buffer

On 5/20/24 10:42 AM, Grisha Levit wrote: If bracketed paste input terminates prior to the paste end sequence, How would this happen? The terminal emulator (or whatever) performing the paste guarantees it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars lon

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

On 5/17/24 11:32 AM, Matheus Afonso Martins Moreira wrote: You don't have to export variables. I would recommend not exporting such a variable to begin with unless you're sure of its effects. It could be made safe so that it's possible to export it. Then it can always be set to some reasonable

[PATCH] bracketed paste unterminated buffer

If bracketed paste input terminates prior to the paste end sequence, the buffer passed to rl_insert_text never gets its null termination. $ bash-asan --norc -in <<<$'\e[200~X' ==15989==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x006167e51260 at pc 0x007e690b5374 bp 0x007ff50ab620 s

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

On 5/20/24 10:07 AM, alex xmb sw ratchev wrote: > FWIW, I was copying the approach from coreutils[1] and gnulib[2]: Sure. I'm going to stick with code clarity and uniformity over micro optimizations here. Maybe I could hide it in a macro. an if overflow sounds like an important t

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

On Mon, May 20, 2024, 15:58 Chet Ramey wrote: > On 5/17/24 5:56 PM, Grisha Levit wrote: > > On Fri, May 17, 2024 at 3:06 PM Chet Ramey wrote: > >> > >> On 5/17/24 12:57 PM, Grisha Levit wrote: > >>> The current cmp implementation for size and blocks subtracts the two > >>> values and returns the

Re: count in vi mode alters prompt

On 5/20/24 9:34 AM, Mohamed Akram wrote: Is there a way to disable this feature, at least in vi mode? No. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/

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

On 5/17/24 5:56 PM, Grisha Levit wrote: On Fri, May 17, 2024 at 3:06 PM Chet Ramey wrote: On 5/17/24 12:57 PM, 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

Re: count in vi mode alters prompt

Is there a way to disable this feature, at least in vi mode? > On May 20, 2024, at 5:27 PM, Chet Ramey wrote: > > On 5/18/24 5:28 PM, mohd.ak...@outlook.com wrote: > >> Bash Version: 5.2 >> Patch Level: 26 >> Release Status: release >> Description: >> When using vi mode in bash, whenever a

Re: count in vi mode alters prompt

On 5/18/24 5:28 PM, mohd.ak...@outlook.com wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When using vi mode in bash, whenever a count is used before a command, bash replaces the prompt with (arg: n) where n is the count entered. This cause

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

> 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. Yes!! Conpletely agree with you!

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

> Are you referring to BASH_SOUCE_PATH being a source-only extension to PATH? I mean that I won't be able to commit a standard loadable script location to my dotfiles repository if setting BASH_SOURCE_PATH changes the behavior of source. It could break too many things. > Yes it allows the locatio

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

On Mon, May 20, 2024 at 4:43 AM Robert Elz wrote: > | A builtin is far more convenient, isn't it? > | Much more ergonomic. > > Only when it is really needed. If there's a standard way of writing multi-script applications (and reusing libraries) in bash, people will ask less about it in SO or