> 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
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 mer
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]?
On Sun, 5 May 2024 at 11:50, Koichi Murase wrote:
> > Ideally, they'll be using bash's native import under the hood!
>
> Yes, module managers still need to implement their own "import"
> command while using the proposed "import" primitive under the hood,
> and it's simply interchangeable with the
>> 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.
It's a native way to load bash scripts for sure.
But it's not a native way to load lib
2024年5月5日(日) 13:36 Matheus Afonso Martins Moreira :
> > If your purpose is just to solve a small inconvenience of the `source'
> > builtin mixing the namespaces of local scripts, "libraries", and
> > executables, I think the suggested `source -i' or `source -l' would be
> > fine. I think no additio
On Sat, May 4, 2024 at 4:44 AM Matheus Afonso Martins Moreira <
math...@matheusmoreira.com> wrote:
>
> By "library system" I just mean the exact mechanism through which
> bash will load a "library". By "library", I mean ordinary scripts
> whose purpose is to collect related functions and variables
On Sun, May 5, 2024 at 7:36 AM Matheus Afonso Martins Moreira
wrote:
> I certainly intend to use it as one should it be merged.
If it's not you should try turning this into a loadable builtin. An
`include' command that lets you selectively import variables/functions
from a larger collection and n
> If your purpose is just to solve a small inconvenience of the `source'
> builtin mixing the namespaces of local scripts, "libraries", and
> executables, I think the suggested `source -i' or `source -l' would be
> fine. I think no additional reasoning is needed.
That is my purpose!
I think I wen
If your purpose is just to solve a small inconvenience of the `source'
builtin mixing the namespaces of local scripts, "libraries", and
executables, I think the suggested `source -i' or `source -l' would be
fine. I think no additional reasoning is needed. In this case, the
"#pragma once" feature wo
> 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
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 f
> 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 a
13 matches
Mail list logo
