Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 11:17 Lawrence Velázquez : > If "import" were qualitatively different from "source" (say it > integrated some sort of namespace functionality), then it would be > more compelling. That sounds interesting. It's a bit unrelated to the main discussion, but I was wondering if it is

Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 9:56 Matheus Afonso Martins Moreira : > The source builtin uses the PATH variable for resolving file names > which means they would have to be placed alongside normal executables > which could cause confusion. You can prepare a separate directory for the script files to source and

Re: [PATCH 0/4] Add import builtin

On Thu, May 2, 2024, at 9:40 PM, Dale R. Worley wrote: > It seems like you could get much the same effect with this device: > > -- > t1 contains: > > # Where I am doing this testing. > BASH_IMPORT_PATH=$HOME/temp/import/t2 > >

Re: [PATCH 0/4] Add import builtin

On Thu, May 2, 2024, at 6:22 PM, Matheus Afonso Martins Moreira wrote: > Bash scripts can be hard to get right so reusing proven solutions > as shell script libraries is of immense value. However, the existing > shell script sourcing mechanisms are suboptimal for this task. > The source builtin

Re: [PATCH 0/4] Add import builtin

It seems like you could get much the same effect with this device: -- t1 contains: # Where I am doing this testing. BASH_IMPORT_PATH=$HOME/temp/import/t2 echo "Note PATH does not contain '.'" echo "PATH=$PATH" echo

Re: [PATCH 3/4] findcmd: define the user import finder function

On Thu, May 2, 2024, at 6:22 PM, Matheus Afonso Martins Moreira wrote: > The find_user_import function looks for executable scripts > in a separate location meant for reusable libraries and modules, > separate from other executables. > > Signed-off-by: Matheus Afonso Martins Moreira > --- >

[PATCH 4/4] builtins: add import builtin

The new import builtin works just like the source builtin but it searches only the directories in BASH_IMPORT_PATH, allowing programmers to create reusable libraries without their scripts needing to be placed in the same locations as normal executable commands or other sourceable scripts.

[PATCH 2/4] findcmd: parameterize path variable in functions

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. Signed-off-by: Matheus Afonso Martins Moreira --- findcmd.c | 25 +

[PATCH 0/4] Add import builtin

Bash scripts can be hard to get right so reusing proven solutions as shell script libraries is of immense value. However, the existing shell script sourcing mechanisms are suboptimal for this task. The source builtin uses the PATH variable for resolving file names which means they would have to be

[PATCH 3/4] findcmd: define the user import finder function

The find_user_import function looks for executable scripts in a separate location meant for reusable libraries and modules, separate from other executables. Signed-off-by: Matheus Afonso Martins Moreira --- findcmd.c | 12 findcmd.h | 1 + 2 files changed, 13 insertions(+) diff

[PATCH 1/4] builtins: extract file content executor function

Extract into a dedicated helper function the code which loads the contents of a file and executes it in the current shell. This separates this useful functionality from the path resolution mechanism used by the source builtin, allowing new functionality to be built upon it. Signed-off-by: Matheus

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

Date:Thu, 2 May 2024 12:17:36 -0400 From:Chet Ramey Message-ID: | It's the reporting part we're talking about here, not the removing. Should be effectively the same thing for the jobs in question (which aren't ones that are stopping) - when a terminated job is

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 5/2/24 1:58 PM, Oğuz wrote: On Thu, May 2, 2024 at 8:44 PM Chet Ramey wrote: I'm not planning to change the text. The point is whether or not this counts as `notification' for the purposes of the jobs list, which allows the shell to remove the job from the list. And what change of

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On Thu, May 2, 2024 at 8:44 PM Chet Ramey wrote: > I'm not planning to change the text. The point is whether or not this > counts as `notification' for the purposes of the jobs list, which allows > the shell to remove the job from the list. And what change of behavior discernible by the average

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 5/2/24 1:38 PM, Oğuz wrote: On Thursday, May 2, 2024, Chet Ramey > wrote: It doesn't. In an interactive shell, while executing a command list, every shell prints a notification if a foreground job is killed by a signal before executing the next comamnd

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On Thursday, May 2, 2024, Chet Ramey wrote: > > It doesn't. In an interactive shell, while executing a command list, > every shell prints a notification if a foreground job is killed by a > signal before executing the next comamnd in the list. Nobody waits > until issuing the next prompt. The

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 5/2/24 12:23 PM, Oğuz wrote: On Thu, May 2, 2024 at 6:10 PM Chet Ramey wrote: There's no real difference between the two statements; there is a clarification for consistency with the language in the new "Job Control" section in Issue 8. Yeah it doesn't clarify anything and the new job

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On Thu, May 2, 2024 at 6:10 PM Chet Ramey wrote: > There's no real difference between the two statements; there is a > clarification for consistency with the language in the new "Job > Control" section in Issue 8. Yeah it doesn't clarify anything and the new job control section is pointlessly

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 4/30/24 12:35 PM, Robert Elz wrote: Date:Tue, 30 Apr 2024 10:29:43 -0400 From:Chet Ramey Message-ID: <958687ce-7e36-42d1-a82e-6101fc777...@case.edu> | That's an interpretation. I might buy it if the DESCRIPTION didn't say | | "When jobs reports the

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

Date:Thu, 2 May 2024 11:10:36 -0400 From:Chet Ramey Message-ID: | There's no real difference between the two statements; there is a | clarification for consistency with the language in the new "Job | Control" section in Issue 8. None of that really matters -

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 5/2/24 9:30 AM, Oğuz wrote: On Thu, May 2, 2024 at 3:55 PM Chet Ramey wrote: A paraphrase of what? Issue 7 says this: By default, the jobs utility shall display the status of all stopped jobs, running background jobs and all jobs whose status has changed and have not been reported by the

Re: macOS 14 objc `+initialize` forced crash due to fork after thread

On 5/2/24 2:23 AM, Tom wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When linked against `libintl.8.dylib`, if an unknown comand is executed, the following error is seen: Where do you get libintl.8.dylib? I don't see it on my macOS systems. And doesn't this

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

At 2024-05-02T16:30:09+0300, Oğuz wrote: > On Thu, May 2, 2024 at 3:55 PM Chet Ramey wrote: > > A paraphrase of what? > > Issue 7 says this: > > By default, the jobs utility shall display the status of all stopped > jobs, running background jobs and all jobs whose status has changed > and have

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On Thu, May 2, 2024 at 3:55 PM Chet Ramey wrote: > A paraphrase of what? Issue 7 says this: By default, the jobs utility shall display the status of all stopped jobs, running background jobs and all jobs whose status has changed and have not been reported by the shell. And Issue 8 draft, this:

macOS 14 objc `+initialize` forced crash due to fork after thread

Forgive me if this is a repost; there appeared to be no path for `bashbug` to respond to me, so I've sent this manually. Configuration Information [Automatically generated, do not change]: Machine: aarch64 OS: darwin23.4.0 Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Darwin

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

On 5/1/24 5:18 PM, Oğuz wrote: On Wed, May 1, 2024 at 10:36 PM Chet Ramey wrote: Sure. Then you wonder why POSIX bothered to include "and all jobs whose status has changed and have not been reported by the shell" in the standard. No, I think it's a botched paraphrase. A paraphrase of