Re: proposed BASH_SOURCE_PATH

On Wed, May 15, 2024 at 7:16 AM Martin D Kealey wrote: > I'm concerned that doing both would introduce an entirely new dichotomy for > programmers to have to remember, so perhaps "skip path searching" should be > controlled by a separate switch, perhaps '-s'? No. `source` already searches PAT

Re: proposed BASH_SOURCE_PATH

On Tue, May 14, 2024 at 3:35 AM Koichi Murase wrote: > > 2024年5月14日(火) 15:09 Martin D Kealey : > > 1. I therefore propose that where a relative path appears in > > BASH_SOURCE_PATH, it should be taken as relative to the directory > > containing $0 (after resolving symlinks), rather than relative t

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

> preparation for a v3 patch set I'm thinking it won't be needed. I just fetched the latest commits and there's already code implementing BASH_SOURCE_PATH. I guess there isn't any point in submitting a new patch set without the other refactoring work I've done. If I can contribute in any other wa

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

> Anyway, there isn't any real reason to modify findcmd.c. > Everything this needs is already available. OK, I will remove it. -- Matheus

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

> This isn't needed given the existence of find_in_path(). OK. I will remove it in preparation for a v3 patch set. -- Matheus

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

> It has been Bash's convention to allow a non-POSIX feature > even in POSIX mode when the script explicitly requests it. I see. I have no objections to that. My initial implementation also worked like this. I did it that way because someone explicitly requested that POSIX mode not be affected in

Re: Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

> If you are talking about the current specific case of path_value, as > Chet has replied, path_value doesn't return a newly allocated block. > It just returns a pointer to an existing variable cell owned and > managed by the global variable context whose root is static. It > doesn't return or move

Re: proposed BASH_SOURCE_PATH

On Tue, 14 May 2024 at 20:10, konsolebox wrote: > On Tue, May 14, 2024 at 2:09 PM Martin D Kealey > wrote: > > 2. Search BASH_SOURCE_PATH when any relative path is given, not just a > path > > that lacks a '/', so that libraries can be organized into subdirectories. > > I disagree with this. Pa

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

In case we talk about different designs, I assume the following one: * `source name' searches the files in BASH_SOURCE_PATH, PATH, and the current working directory. * `source -i name', if it would be added, searches the files in BASH_SOURCE_PATH (excluding PATH and the current working directory u

Re: [PATCH v2 8/8] shell: restrict BASH_SOURCE_PATH when appropriate

> Or you could simply ignore BASH_SOURCE_PATH in restricted mode. Then the restricted shells will not have access to this new functionality. I thought it could be useful if properly integrated. > Or, at least, this should be an opt-in > feature that the scripts to set up the > restricted shells n

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

I agree that it is not strictly necessary. It could be implemented without an option. I personally have no objections to that solution. My arguments for the option are the following: - It enhances compatibility Without the option, source behaves exactly as before. Existing scripts will wor

Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.

On Fri, 26 Apr 2024 at 15:10, Chet Ramey wrote: > > On 4/25/24 9:56 PM, Dan Shelton wrote: > > >> Everyone seems to support MAKEFLAGS by now, and it's part of POSIX, so > >> maybe we delete $(MFLAGS) and rely on make to pass MAKEFLAGS to submakes > >> in the environment. > > > > Could you do this

Re: Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

2024年5月14日(火) 12:32 Matheus Afonso Martins Moreira : > > The patches touch the interface of many functions > > I added one external function: find_in_path_var. > The other changes are all static and local. > > > It seems essentially equivalent to just calling > > find_in_path (list->word->word,

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

Date:Tue, 14 May 2024 15:51:10 -0400 From:Chet Ramey Message-ID: | What do folks think about forcing an option to enable using | BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally | think it is not.) We discussed this briefly last week but

Re: proposed BASH_SOURCE_PATH

This needs to resolve symbolic links otherwise path will be that of the symbolic link rather than that of the actual script file: There are already ways to safely allow sourcing libraries relative to a bash script installation without adding features to Bash: # Create tests and library fold

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月15日(水) 5:16 Chet Ramey : > On 5/13/24 10:53 PM, Matheus Afonso Martins Moreira wrote: > >> I think we should restrict the search in > >> BASH_SOURCE_PATH and shouldn't fall back to local files. > > > > I concur but thought it'd be wise to discuss it first so I left it in. > > Searching the c

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月15日(水) 5:02 Chet Ramey : > > In that case, > > we need to make sure that `find_in_path_var()' returns NULL in the > > case of empty BASH_SOURCE_PATH. > > Do you mean BASH_SOURCE_PATH= ? Yes. Or more precisely, I intended to include both `BASH_SOURCE_PATH=' and `unset -v BASH_SOURCE_PATH'.

Re: [PATCH v2 8/8] shell: restrict BASH_SOURCE_PATH when appropriate

2024年5月15日(水) 4:55 Chet Ramey : > On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: > > Make the BASH_SOURCE_PATH variable read-only and unsettable > > when the shell is operating in restricted mode. This variable > > should be restricted for the same reasons why PATH is restricted. > > Or

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

2024年5月15日(水) 4:51 Chet Ramey : > What do folks think about forcing an option to enable using > BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally > think it is not.) We discussed this briefly last week but without any > conclusion. Either works for me (suppose the `source' bu

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

On 5/13/24 10:53 PM, Matheus Afonso Martins Moreira wrote: I think we should restrict the search in BASH_SOURCE_PATH and shouldn't fall back to local files. I concur but thought it'd be wise to discuss it first so I left it in. Searching the current directory is the existing behavior (albeit

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

On 5/13/24 11:32 PM, Matheus Afonso Martins Moreira wrote: The patches touch the interface of many functions I added one external function: find_in_path_var. The other changes are all static and local. It seems essentially equivalent to just calling find_in_path (list->word->word, path_v

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

On 5/13/24 7:47 PM, Koichi Murase wrote: 2024年5月13日(月) 19:38 Matheus Afonso Martins Moreira : The PATH variable is hard coded in the user command finder function. Transforming it into an argument allows reusing the file finding logic with variables other than PATH, making the code more flexible.

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

On 5/13/24 7:39 PM, Koichi Murase wrote: * With this, `isolated_search_for_file()' falls back to local files in the current working directory. I'm unsure about whether this is intentional, but I think we should restrict the search in BASH_SOURCE_PATH and shouldn't fall back to local files. You

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

On Tue, May 14, 2024, at 3:51 PM, Chet Ramey wrote: > On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: >> Passing the -i option to the source builtin >> enables isolated sourcing mode which restricts >> its search path to the directories defined by >> the BASH_SOURCE_PATH variable. This al

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

On Tue, May 14, 2024 at 03:51:10PM -0400, Chet Ramey wrote: > On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: > > Passing the -i option to the source builtin > > enables isolated sourcing mode which restricts > > its search path to the directories defined by > > the BASH_SOURCE_PATH varia

Re: [PATCH v2 8/8] shell: restrict BASH_SOURCE_PATH when appropriate

On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: Make the BASH_SOURCE_PATH variable read-only and unsettable when the shell is operating in restricted mode. This variable should be restricted for the same reasons why PATH is restricted. Or you could simply ignore BASH_SOURCE_PATH in re

Re: [PATCH v2 7/8] variables: define default BASH_SOURCE_PATH

On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: Define a build time configurable default value for the new BASH_SOURCE_PATH variable. Look for libraries in the user's home directory as well as the system wide directories. I don't like bash providing a default for this when bash doesn'

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

On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: Passing the -i option to the source builtin enables isolated sourcing mode which restricts its search path to the directories defined by the BASH_SOURCE_PATH variable. This also has the added benefit of not touching PATH at all. What do

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: The PATH variable is hard coded in the user command finder function. Transforming it into an argument allows reusing the file finding logic with variables other than PATH, making the code more flexible. This isn't needed given the existe

Re: bug in bash

On 5/14/24 11:12 AM, Chet Ramey wrote: On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to

Re: logic in m4/strtoimax.m4 inverted

On Mon, Oct 3, 2022 at 12:48 PM Chet Ramey wrote: > > On 10/1/22 6:38 AM, Emanuel Haupt wrote: > > Static build of 5.2 fails to build on FreeBSD 13.1-RELEASE (amd64). > > > > The logic in m4/strtoimax.m4 is inverted. The following patch replaces > > strtoimax() if and only if it is present and fun

Re: logic in m4/strtoimax.m4 inverted

On 5/14/24 11:17 AM, Evan Gates wrote: On Mon, Oct 3, 2022 at 12:48 PM Chet Ramey wrote: On 10/1/22 6:38 AM, Emanuel Haupt wrote: Static build of 5.2 fails to build on FreeBSD 13.1-RELEASE (amd64). The logic in m4/strtoimax.m4 is inverted. The following patch replaces strtoimax() if and only

Re: bug in bash

On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to kill a procsub when you interrupt the j

Re: Changed behaviour of ${PARAMETER/#PATTERN/STRING} and ${PARAMETER/%PATTERN/STRING}

On 5/13/24 12:04 PM, Andreas Schwab wrote: In 5.3-alpha, it is no longer possible to quote the special % and # characters in a pattern replacement expansion. $ a=1/%2/%3 $ echo "${a/\%/##}" 1/%2/%3## Interesting. This is actually the result of the (seemingly unrelated) https://lists.gnu.org/a

Re: bug in bash

On Mai 14 2024, Chet Ramey wrote: > Setting the process group might solve this particular issue, at the cost of > losing keyboard-generated signals. That's not so bad for SIGINT, though > people do expect to be able to kill a procsub when you interrupt the job > using it, but you also wouldn't be

Re: bug in bash

On 5/13/24 3:37 PM, Oğuz wrote: On Monday, May 13, 2024, Chet Ramey > wrote: performs the setpgid in the process forked to run the process substitution). Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout

Re: proposed BASH_SOURCE_PATH

Le 14/05/2024 à 08:08, Martin D Kealey écrivait : I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would like to suggest three tweaks to its semantics. A common pattern is to unpack a script with its associated library & config files into a new directory, which then leaves a

Re: proposed BASH_SOURCE_PATH

2024年5月14日(火) 15:09 Martin D Kealey : > 1. I therefore propose that where a relative path appears in > BASH_SOURCE_PATH, it should be taken as relative to the directory > containing $0 (after resolving symlinks), rather than relative to $PWD. > > As an interim step until that's implemented, please

Re: proposed BASH_SOURCE_PATH

On Tue, May 14, 2024 at 2:09 PM Martin D Kealey wrote: > 1. I therefore propose that where a relative path appears in > BASH_SOURCE_PATH, it should be taken as relative to the directory > containing $0 (after resolving symlinks), rather than relative to $PWD. This implies only the directory where