> 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
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 module
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
> 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日(火) 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. T
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]?
> as long as there's no expectation that I'll accept a new feature
> just because someone implemented it.
There is certainly no expectation of the sort. Thanks for considering the patch.
Matheus
> 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. Users who need just that core
feature need not pull in an entire module manager just to get it.
So for those use
On Mon, May 6, 2024, at 1:27 AM, Matheus Afonso Martins Moreira wrote:
>> 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
> 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 5/6/24 1:27 AM, Matheus Afonso Martins Moreira wrote:
Either you add the library directories to the PATH and risk false positives,
or you delete the other directories and make sourced scripts unable to run
commands.
External commands, but there is nothing preventing something like a
`regis
On 5/6/24 1:21 AM, Phi Debian wrote:
On Sun, May 5, 2024 at 9:47 PM Greg Wooledge wrote:
On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote:
The idea to add a BASH_SOURCE_PATH variable that gets searched before, or
instead of, PATH when using the source builtin -- that sounds
On 5/7/24 2:43 AM, Kerin Millar wrote:
Of course, it is sensible to gauge whether there is any potential interest in a
proposed feature prior to submitting patches. Matheus tried to do exactly that
on the 21st April. I may think that the resulting patches have been oversold but
I would not fau
On 5/7/24 12:24 AM, Phi Debian wrote:
Just questioning, I really have no idea what is the bash dev team way of
receiving enhancement request.
This list is the traditional place where proposals and discussion happen.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 5/6/24 9:12 AM, Koichi Murase wrote:
Chet mentioned the additional variable for the locations to search,
but not a new builtin or a flag.
Correct. The $PATH overloading has always been a source of confusion,
or at least something you need to get used to; it would be a benefit
to have a way
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
Ok thanx for clarification.
I agry about git{lab,hub} position that's why I added {,whatever} meaning
something really free.
Ok now all is clear and I will not be surprised anymore if some other
'feature' proposal shows up in the future.
On Tue, 7 May 2024, at 5:24 AM, Phi Debian wrote:
> On Mon, May 6, 2024 at 7:51 PM Kerin Millar wrote:
>>
>>
>> I'll put it in a little more detail, though no less plainly. I find the
>> terminology of "libraries" and "modules" to be specious in the context of a
>> language that has no support
On Mon, May 6, 2024 at 7:51 PM Kerin Millar wrote:
>
>
> I'll put it in a little more detail, though no less plainly. I find the
> terminology of "libraries" and "modules" to be specious in the context of a
> language that has no support for namespaces, awkward scoping rules, a
> problematic impl
On Mon, 6 May 2024, at 6:11 PM, Matheus Afonso Martins Moreira wrote:
>>> 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
>> 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 Sun, May 5, 2024 at 9:47 PM Greg Wooledge wrote:
> On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote:
>
>
> The idea to add a BASH_SOURCE_PATH variable that gets searched before, or
> instead of, PATH when using the source builtin -- that sounds good. I
> don't really underst
On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote:
> Much like the periodic requests for XDG-organized startup files, a
> BASH_SOURCE_PATH might be convenient but is not groundbreaking and
> probably doesn't merit significant changes to the shell. I'm not
> even convinced it merit
On Sun, May 5, 2024, at 12:35 AM, Matheus Afonso Martins Moreira wrote:
> I agree that a one line of code reduction is underwhelming
> but that's not the only reason to include it. The users are the
> main beneficiaries. This gives users a simple way to load
> modules without using any module manag
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
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 i
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
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
PATH=$BASH
> 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
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
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 possib
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 put
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
>
> echo
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 use
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 "BASH_IMPORT_
54 matches
Mail list logo
