Re: Re: Re: [PATCH 0/4] Add import builtin

> If the purpose is to introduce a standard module system in Bash, > I'll have to be opposed to the change because I think the current > suggestion for `source -i' wouldn't help satisfy that purpose at all. I think we were unable to reach an understanding because we were both using the same words

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

> Oh, I see, from gettext-0.22. Yes, that's right, this came up in the context of a [macports bug report][1]. > Still, how should bash avoid this using only public function interfaces? That report has a work-around invoking a syntax error which presumably calls out to `setlocale`/`gettext`

Re: [PATCH 0/4] Add import builtin

Date:Fri, 3 May 2024 09:18:09 -0400 From:Chet Ramey Message-ID: <842de6ec-c7f9-47fb-ab21-e25c0bfd8...@case.edu> | How is this any different than | | PATH=$BASH_IMPORT_PATH:$PATH source | or | PATH=$BASH_IMPORT_PATH source | | You could force the latter

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

Date:Fri, 3 May 2024 13:11:00 -0400 From:Chet Ramey Message-ID: | >> ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID ) | > | > Never seen this and it's ugly too. Oh well, at least it doesn't show | > the expanded arguments. | | It's been

Re: Re: Re: [PATCH 0/4] Add import builtin

I think we can separate the discussion about the module system and the source builtin. What is the primary purpose or the reasoning behind the suggestion? If the purpose is to introduce a standard module system in Bash, I'll have to be opposed to the change because I think the current suggestion

Re: Re: Re: [PATCH 0/4] Add import builtin

> it doesn't need to be implemented as a builtin It doesn't need to be implemented this way.. But it could be. It's true that a whole new builtin was overkill but the discussion still pointed to a better solution in the form of source --import. This is a more conservative approach but it's still

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

On 5/3/24 12:04 PM, Oğuz wrote: On Fri, May 3, 2024 at 6:41 PM Chet Ramey wrote: We're only talking about interactive shells here. Non-interactive shells have printed something like this, but including the pid, for forever: ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID )

Re: Re: [PATCH 0/4] Add import builtin

> How is this any different than The main advantage would be availability of this mechanism by default in all new versions of bash. This would make it "native" to the language, the path of least resistance to reusing bash code. Users will be able to just place the scripts in the appropriate

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

On 5/3/24 10:36 AM, Oğuz wrote: On Friday, May 3, 2024, Chet Ramey > wrote: Which is more confusing? The latter, it doesn't say what was killed. The former looks different from what `jobs' prints and is more informative so it would be nice to have in an

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

On Fri, May 3, 2024 at 6:41 PM Chet Ramey wrote: > We're only talking about interactive shells here. Non-interactive shells > have printed something like this, but including the pid, for forever: > > ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID ) Never seen this and it's ugly

Re: Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 14:45 Matheus Afonso Martins Moreira : > This is suboptimal. In case the library script cannot found > in the intended directories, it will needlessly search every > other entry in PATH for it, despite the fact they will contain > only unsuitable executables and programs. There is no

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

On Friday, May 3, 2024, Chet Ramey wrote: > > Which is more confusing? > The latter, it doesn't say what was killed. The former looks different from what `jobs' prints and is more informative so it would be nice to have in an interactive shell. Not sure how people would react if their scripts

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

On 5/1/24 10:38 PM, Koichi Murase wrote: 2024年5月1日(水) 22:58 Chet Ramey : Yes, and I said I could work around this case. Thank you for your consideration. [1] https://lists.gnu.org/archive/html/bug-bash/2022-10/threads.html#00054 [2]

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

On 5/2/24 10:54 AM, Chet Ramey wrote: 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

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

On 5/2/24 1:44 PM, Chet Ramey wrote: I think we're talking about two different categories of notifications though; the one sent when a foreground job is killed is useful when the shell is non-interactive too, the other not so much. I don't know why the standard doesn't cover it, but if you

Re: [PATCH 0/4] Add import builtin

On 5/2/24 6:22 PM, Matheus Afonso Martins Moreira wrote: This patch set introduces a new "import" builtin which behaves just like the source builtin but only looks up executables in the BASH_IMPORT_PATH variable. How is this any different than PATH=$BASH_IMPORT_PATH:$PATH source or

Re: Re: [PATCH 0/4] Add import builtin

> You can prepare a separate directory for the script files to source > and put the directory name at the beginning of PATH, e.g., > PATH=~/.config/bash/functions:$PATH. This is suboptimal. In case the library script cannot found in the intended directories, it will needlessly search every

Re: Re: [PATCH 0/4] Add import builtin

> This is debatable. Augmenting PATH with a directory containing > nonexecutable scripts for sourcing is IMO not that confusing. That was my original intention but there were objections to overloading the source builtin with even more behavior. I thought it was a good point so I decided to

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

> Why does this only find executable files? My intention was to eliminate as many non-candidate entries as possible. For example, developers might put data files among the code files, it would be useful if they were not searched. That's why I also set the no direcrories flag. I admit I was

Re: Re: [PATCH 0/4] Add import builtin

> By the name "import", I expect also something like an include guard, > i.e., it loads the same file only once at most. This is an excellet idea. I'll try to implement it. Matheus

Re: [PATCH 0/4] Add import builtin

On Fri, May 3, 2024 at 5:26 AM Koichi Murase wrote: > > > By the name "import", I expect also something like an include guard, > i.e., it loads the same file only once at most. I have a > shell-function implementation,`ble-import', in my framework. It > doesn't support namespace, but it supports