> Backwards compatibility from the ancient past. Even back then (1989),
> `type' was the only builtin that supported any kind of long option;
> no other builtins ever have.
I see, thanks for clarifying. I will remove the long options.
-- Matheus
On 5/8/24 2:07 PM, Dale R. Worley wrote:
"Kerin Millar" writes:
On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote:
anonymous writes:
[...]
It's likely that your reply will never be seen by the anonymous
Savannah issue filer.
OK. Now does that mean that there is no way for me to
> This is your key assertion, and it does not appear to have achieved
> consensus.
That's true, unfortunately.
>> The behavior of the source builtin already has several special cases.
> Do you mean the treatment of the DEBUG trap? That's for the debugger.
I mean that the source builtin already
> Neither of these requires a new builtin command.
> They require changes to the shell, since they differ from
> existing functionality, but those changes don't have to
> take the form of a builtin.
Builtin was not the correct word for what I meant.
I meant to say there were advantages to
On Wed, 8 May 2024, at 7:07 PM, Dale R. Worley wrote:
> "Kerin Millar" writes:
>> On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote:
>>> anonymous writes:
[...]
>
>> It's likely that your reply will never be seen by the anonymous
>> Savannah issue filer.
>
> OK. Now does that mean that
On Wed, May 08, 2024 at 02:07:55PM -0400, Dale R. Worley wrote:
> "Kerin Millar" writes:
> > On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote:
> >> anonymous writes:
> >>> [...]
>
> > It's likely that your reply will never be seen by the anonymous
> > Savannah issue filer.
>
> OK. Now
"Kerin Millar" writes:
> On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote:
>> anonymous writes:
>>> [...]
> It's likely that your reply will never be seen by the anonymous
> Savannah issue filer.
OK. Now does that mean that there is no way for me to effectively
suggest a solution (and so
On 5/8/24 7:09 AM, Matheus Afonso Martins Moreira wrote:
In these discussions we've managed to
discover at least two *concrete* reasons
why it should actually be a builtin.
- It can avoid touching PATH.
Pure shell import cannot.
- It's compatible with restricted shells.
Most
On 5/8/24 4:37 AM, Koichi Murase wrote:
2024年5月8日(水) 8:11 Matheus Afonso Martins Moreira :
Some builtins do support long options, even though it seems
to not be documented.
I didn't know the `type' builtin recognizes those forms.
Backwards compatibility from the ancient past. Even back then
On 5/8/24 3:45 AM, Koichi Murase wrote:
As an alternative option, is it possible that the `.' builtin follows
POSIX while the `source' builtin has the extension of
BASH_SOURCE_PATH? I don't have a particular preference here, but I'm
just curious about if there is a reason or motivation that the
On 5/7/24 8:53 PM, Matheus Afonso Martins Moreira wrote:
Surely these module managers do more than simply implement an
alternate search path?
Yes. The core feature that they provide, namely module loading,
should be native to bash though.
This is your key assertion, and it does not appear to
On 5/7/24 7:11 PM, Matheus Afonso Martins Moreira wrote:
If you consider the current form would be complete, you should provide
the reason that the other builtins should not have the long form of
the options, while only the source builtin should have a long option.
I don't understand why they
> I've checked the behavior, where the `source' builtin seems to still
> load the non-executable one found first in the path.
I was wrong about that. I derived find_user_library
from find_user_command. That's what I had in mind.
> How do you define `the libraries' out of a wider category of Bash
On Fri, May 3, 2024 at 10:53 PM Koichi Murase wrote:
> [1]
> https://github.com/niieani/bash-oo-framework?tab=readme-ov-file#using-import
> [2]
> https://github.com/akinomyoga/ble.sh/wiki/Manual-%C2%A78-Miscellaneous#user-content-fn-ble-import
> [3]
>
2024年5月8日(水) 9:13 Matheus Afonso Martins Moreira :
> Please let me know if you agree to any of the following paths:
>
> ~/.local/share/bash:/usr/share/bash
> ~/.local/share/bash/lib:/usr/share/bash/lib
The former is absolutely no. If we choose that location to store
scripts, no place is
2024年5月8日(水) 8:11 Matheus Afonso Martins Moreira :
> Some builtins do support long options, even though it seems
> to not be documented.
I didn't know the `type' builtin recognizes those forms.
> Also, I do realize that there's a big all caps warning
> in the file saying that "THIS SHOULD REALLY
2024年5月8日(水) 6:13 Matheus Afonso Martins Moreira :
> > By exposing this function in `common.h',
> > this effectively becomes a part of the public
> > interface for loadable builtins.
>
> [...]
>
> Are all external functions defined in all files inside the
> builtins directory exposed as part of a
2024年5月8日(水) 7:12 Matheus Afonso Martins Moreira :
> > a language that has no support for namespaces, awkward scoping rules,
> > a problematic implementation of name references, and so on.
>
> I could at least attempt to address those issues.
I don't think these are requests to you. Those topics
2024年5月7日(火) 23:17 Chet Ramey :
> On 5/6/24 1:21 AM, Phi Debian wrote:
> > Well even this is unclear 'BASH_SOURCE_PATH get searched before PATH' or
> > 'BASH_SOURCE_PATH get searched instead of' or even 'BASH_SOURCE_PATH get
> > searched after PATH'
>
> Because we haven't discussed the semantics.
2024年5月7日(火) 21:40 Martin D Kealey :
> I wonder if it would be useful to add options to 'command':
Thanks for your suggestion. I still think those should be implemented
by shell functions, but that interface sounds interesting. That seems
to cover most of the cases I raised. However, those are
2024年5月7日(火) 2:11 Matheus Afonso Martins Moreira :
> >> A native way to source libraries. Built into bash, available to all users.
> > That's the source builtin.
>
> It looks for scripts in directories meant for executables.
> It prefers files with the executable bit set.
Is this related to [1]?
21 matches
Mail list logo
