> 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 b
> 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 implemen
> 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]
> https://github.com/basherpm/basher?tab=read
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日(火) 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]?
> 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.
Namespacing could be as simple as prepending the module name
to the symbols that are being created. Bash seems to
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月6日(月) 14:28 Matheus Afonso Martins Moreira :
> > I fail to see how this could possibly save "thousands and thousands
> > of lines of code".
>
> How many lines of code were needed to implement the module managers?
> Probably a lot of lines. I guessed it was in the "thousands of lines"
> ball
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
> Your proposition could not be 'builtin', you want a new 'model' with
> 'packages/module'
Yes. However, that was because I did not really know bash module managers
existed.
I immediately adopted a conservative approach once I was informed of their
existence.
I do not intend to develop the imp
On Mon, May 6, 2024 at 7:28 AM Matheus Afonso Martins Moreira <
math...@matheusmoreira.com> wrote:
> Yet the feature has been described as "irritating"!
> I really don't understand the cause for this
> and it's making me feel really unwelcome.
>
I think it is not personnal, you proposed something
> I fail to see how this could possibly save "thousands and thousands
> of lines of code".
How many lines of code were needed to implement the module managers?
Probably a lot of lines. I guessed it was in the "thousands of lines" ballpark.
However many lines that is, this feature would allow me
t
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
> 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 locat
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
> 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
othe
> 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 prot
> 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
27 matches
Mail list logo
