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

[Koichi Murase]

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]?

[1] https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00132.html

I've checked the behavior, where the `source' builtin seems to still
load the non-executable one found first in the path.

  $
  GNU bash, version 5.3.0(1)-alpha (x86_64-pc-linux-gnu)
  $ ls -l t/bin{1,2}/file
  -rw-r--r-- 1 murase murase 15 2024-05-08 11:27:33 t/bin1/file
  -rwxr-xr-x 1 murase murase 15 2024-05-08 11:27:25 t/bin2/file
  $ head t/bin{1,2}/file
  ==> t/bin1/file <==
  echo bin1/file

  ==> t/bin2/file <==
  echo bin2/file
  $ (PATH=t/bin1:t/bin2 source file)
  bin1/file

> It's a native way to load bash scripts for sure.
> But it's not a native way to load libraries.

How do you define `the libraries' out of a wider category of Bash
scripts intended to be sourced? Even if they are distinct from other
types of Bash scripts, they are still a subcategory of Bash scripts.
Then, the source builtin is also a native way to load libraries. Maybe
you mean a dedicated way by "the native way", but I don't see the
necessity of having a dedicated way.

> > It's just your expectation of the ergonomics but not ours.
>
> What are your expectations?

The answer is found later in the same paragraph as the above sentence.
I mean the community by `ours' but not specifically mine. There are
existing implementations of module managers, which you don't seem to
have yet performed a survey, and which are not just simple as yours.
Of course, existing implementations are not designed by
anti-ergonomics, and there should be ergonomics by the respective
designers.

> Do you really think it's reasonable to suggest that
> users implement their own library importing function?

No. I just think it's unreasonable to force everyone to use a specific
way of module management that you are trying to invent without
referencing existing implementations.

> The fact such a function can be written in bash
> is evidence of how powerful bash is. It doesn't
> really follow though that everything that can be
> written in bash should be done in bash.

Right, but the reserve is not true either. I don't think everything
that is significantly complicated to show the power of Bash should be
a builtin.

> > He submitted patch seems unneededly large.
>
> The diffstat shows 9 files changed,
> 203 insertions, 92 deletions.

The number of lines being 203 is definitely large.

> Most of those are very simple
> refactorings of existing code.

I now know the reason. There are additional refactorings.

> > incomplete addition of the long option of builtins
>
> What do you mean? What is missing?
>
> > an incomplete support for the XDG base directories, which should
> > actually be discussed separately.
>
> XDG does not specify the ~/.local and ~/.local/lib directories. [...]

I've replied to them in respective patches.

> >  It does seem your personal hangup not giving a filename extension to
> > the script files, which ended up with mixed script files to be sourced
> > and executable files.
>
> Whether to use file extensions or not is the user's choice.
> Bash should work correctly regardless of what the file name is.

Right. At the same time, more or less, it is the user's responsibility
to avoid name conflicts between a script file and an executable file
just like it is between two script files to be sourced. But I agree
that the situation of the mixed script files and executable files can
be improved.

> > If you think that is the problem, your suggestion doesn't actually
> > solve the problem of module managers.
>
> I didn't think it was a problem at first. I just thought it was unnecessary.
> Bash already knows how to do it. We should make it do it for us.
>
> Now I do see it as a problem to be solved. Bash has a restricted shell mode
> which, among many other things, prohibits slashes in file names passed to
> the source builtin. If things are as you claim and the module managers really
> do resolve the paths themselves in order to pass an absolute path to source,
> that means they are all incompatible with bash's restricted shells.
> The proposed native implementation of the module loader is not.

I haven't thought about the restricted shells.

After thinking about it, I think the suggested feature itself should
probably be disabled under the restricted shell since similar features
such as `enable -f' and `command -p' are also disabled in the
restricted shell. If it would be enabled, BASH_SOURCE_PATH should be
at least readonly the same as PATH. Also, administrators who prepare a
restricted shell environment need to carefully set BASH_SOURCE_PATH to
be a restricted one. However, it would still be a loophole for old
setups for the restricted shell that don't take account of
BASH_S

Re: [PATCH 0/4] Add import builtin

[Koichi Murase]

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. There shouldn't be any changes
> in posix mode, so that will continue to use PATH.

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
`source' builtin should also follow POSIX.

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

[Koichi Murase]

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 merely
examples I know, and I still think it would be better to leave the
degrees of freedom for module managers.

> * '-o' would report only the first command found (when more than one is 
> given) (or could be '-1');
> * '-p' would skip builtins &  functions, and fail silently if no file can be 
> found;
> * '-x' would search for files that lack exec permission.

Maybe I'll attempt a shell-function implementation of this interface.

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

[Koichi Murase]

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 (in particular
the scoping and namerefs) are the ones that repeatedly pop up in the
bug-bash list. Each single topic could be a project that takes years.

Also, if you start to implement those (and the `load once' feature), I
need to go back to the arguments of the standard module manager. There
are existing module managers implemented by shell functions, which are
based on years of practices. Then, you cannot ignore them.

> Namespacing could be as simple as prepending the module name
> to the symbols that are being created.

I don't think that works consistently. The shell language is
inherently dynamic, so it isn't possible to resolve everything
statically at the loading time. What happens when a function is called
by its name stored in a variable passed through the caller's
parameter? What happens when a variable is referenced by its name
similarly? The behavior is unpredictable.

Also, if you consider implementing a namespace, I think you should
first check the ksh's implementation of namespace and learn what would
be the good points and what could be the practical problem there.

Re: Re: [PATCH 1/9] builtins: extract file content executor function

[Koichi Murase]

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 public API/ABI?

No.

> If that's the case, then it should also be made static
> as you suggested.

Even if it's not the case, I think one should mark it as `static' as
far as the function is not used by other translation units. Even if
it's not the interface exposed to the users, it's still an interface
for other translation units, and it's a premature exposition of
abstraction at present. No other translation units are using the
function.

> Can you break down for me which parts of the code base
> are public and which are private? This will allow me to
> avoid making such mistakes in the future.

You can check /examples/loadables/loadables.h in the tree. The headers
included from there (and further headers included thereby) are
explicitly the interface that the users can use to implement a
loadable builtin. For a wider public interface, you can look inside
the directory `$prefix/include/bash' (and subdirectories therein)
after running `make install'.

> I'd also like to suggest creating a private commons.c
> file where potentially reusable functionality can be
> moved to without exporting them.

I think such a feature should go into a related file in the main directory.

Re: [PATCH 4/9] bashgetopt: define long option shortener function

[Koichi Murase]

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 GO AWAY".
> I get the message, but I'm honestly not sure what
> that's referring to. The obsolescent options,
> the long options, the hack to handle them?
> All of this stuff? Not sure.

> The builtins seem to be quite consistent
> in their support for --help though.
> So there's at least some precedent
> for long option support.

I've been accepting the `--help' option because it is somewhat
special. When people do not know even whether the command supports a
long form of the options, they still want to get a help text. Then,
they typically attempt ` --help'.

> > 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 don't all have long options to begin with.
> Is there a reason for it?

I don't know the true reason, but at least it's tradition. It's been
this way for a long time.

> > I don't think those changes are allowed to slip in as a bonus
> > of another change on the source builtin.
>
> Well I'm not really trying to "slip in" anything.
> That implies I'm deceptively trying to get my way.
> I'm not. I just thought it would be a nice feature to have.

I wouldn't call it `deceptive', but by mixing the change in a larger
patch, the change has more chance to go into the codebase without
being focused by the reviewers and without being discussed
sufficiently as they would have if they were in a separate suggestion.

> If it's not acceptable, I can and will remove the long options.

This is my opinion: You can just remove the support for the long
option from the present patch set. If you are willing, you should
create another discussion in the bug-bash list (not in the help-bash
list), and then if accepted, complete the long options for all the
builtins, and re-submit the patch after that. The current introduction
of the long option is not in a complete form.

> > I'm not sure about what Chet thinks, but I don't think those are
> > really necessary, though it's a better design in general.
>
> I'll wait for his review.

> > I also have thoughts on the way how this was implemented, but I
> > wouldn't discuss it for now.
>
> Please do. If the implementation can be improved, I will do it.

I'm not sure if the full support for the long options would be
accepted by the community so wouldn't like to spend time to nicely
explain them at present. If you are fine with random sentences, it
doesn't work with `source -- --library' when one wants to source a
file of the actual name `--library'. This is a hypothetical case, but
still conflicts with the standard processing of the command-line
arguments. The hidden options of the `type' builtin have the same
issue. Next, there is already the `--help' option. If the long option
would be officially supported, the processing of `--help' and the
other long options should be consistent. We don't want to use two
different mechanisms to handle the long options at the same time.
Third, the `const char to;' should be `const int to;' to make it
consistent with the return type of `internal_getopt'. In particular,
this is not forward compatible when we want to add a long option that
doesn't have a corresponding short form, in which case one should
choose an integer that doesn't overlap with a char value (as seen in
the negative values of GETOPT_EOF and GETOPT_HELP). However, I have to
say there is also an issue in the existing choices of -1 and -99
because `char' is signed in typical C implementations and thus has the
range -128..127. We don't usually use the negative range (i.e., C1 and
GR in ASCII or the leading byte of a multibyte character) as an option
letter, but it's better to avoid.

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

[Koichi Murase]

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 left for the future addition of other types of
files. The latter style (but with `lib' being replaced by another word
if necessary as in an ongoing discussion about the name `library')
should be fine.

Even if it would finally be `library', I suggest that the directory
name `lib' should instead be `library' or `libraries' because
inexperienced users can be easily confused with the dynamic library
location `lib' when a script framework instructs the users to put
their script files in `share/bash/lib'. Even if we explicitly instruct
the users to put them in `/usr/share/bash/lib', some users still try
to put them in `/usr/lib' for some mysterious reason. It would
probably happen when `/usr/share/bash/lib' doesn't work for another
reason, and users try to put them directly in `/usr/lib` to "solve"
the problem. That happened with my framework. I named the directory of
the script files as `lib', which I regret now.

> Note that the default value of XDG_DATA_HOME
> is defined to be ~/.local/share.

In this case, I think the default value should actually honor the
value of XDG_DATA_HOME if present (instead of hard-coding it to be
~/.local/share).

  BASH_SOURCE_PATH=${XDG_DATA_HOME:-$HOME/.local/share}/:...

Then, there arise the repeated arguments of the chicken or the egg of
the XDG base directory initialization. Since XDG_DATA_HOME is supposed
to be set by the user in .bash_profile (or similar initialization
file), the prefered value of XDG_DATA_HOME is not known at the
initialization stage of login sessions of Bash.

> I'm not exactly invested in getting any XDG stuff
> into bash but it seems like a reasonable enough
> default for the user's personal libraries directory.

As mentioned above, it's useful but there is an issue of the chicken
or the egg. The user sets values to the variables in the shell, but
the shell wants to know the value of the variables to initialize it on
its startup. Some alternative ways are proposed, but a clean way
hasn't yet appeared.

I think it would be better to just confine ourselves in a similar
default as BASH_LOADABLES_PATH within this patch. The choices for the
location in the home directory can be discussed with the approach to
the XDG base directories.

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

[konsolebox]

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=readme-ov-file#sourcing-files-from-a-package-into-current-shell
> [4] https://github.com/modernish/modernish?tab=readme-ov-file#simple-form
> [5] 
> https://github.com/bash-bastion/basalt/blob/main/docs/reference/api.md#basaltload
> [6] https://github.com/ko1nksm/modulesh/blob/master/README.md#import
> [7] 
> https://github.com/scop/bash-completion/blob/c48854850f702604aeb600ae496fb6b2eb840f8e/bash_completion#L3127
> [8] 
> https://github.com/ohmybash/oh-my-bash/blob/9cfb35c946953cb8cc1511cce47986cdd630852a/oh-my-bash.sh#L52

You might want to add my 15-year-old framework too. Thank you very much. :)

https://loader.sourceforge.io/overview/


-- 
konsolebox

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

[Matheus Afonso Martins Moreira]

> 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
> scripts intended to be sourced?

Intended purpose. As I've described in other emails,
the lines can get blurry. The reliable way is to look at
the way the developer intended it to be used.

> No. I just think it's unreasonable to force everyone to use a specific
> way of module management that you are trying to invent without
> referencing existing implementations.

No one's being forced to do anything though.

> Right, but the reserve is not true either. I don't think everything
> that is significantly complicated to show the power of Bash should be
> a builtin.

I never used that argument to begin with.
I always maintained that building this into
bash is the better solution.

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 managers resolve the path
   and pass in absolute file names, as you noted.

These points are not "personal hangups".
Those are real limitations, present in module managers,
that this patch overcomes by virtue of being a builtin.

> The number of lines being 203 is definitely large.

Definitely large? I don't know about that.
I even split it up into logical changes.
I have no idea what the problem is.
Are you saying it's difficult to review the patch?

> I now know the reason. There are additional refactorings.

So you hadn't actually read the patch until now?

> Right. At the same time, more or less, it is the user's responsibility
> to avoid name conflicts between a script file and an executable file
> just like it is between two script files to be sourced.

Why is responsibility being brought up?
Bash can help the user by supporting separate paths.
If bash can help the user, then it should help the user.
Empowering and helping the user
is the software's reponsibility.

> But I agree that the situation of the mixed script files
> and executable files can be improved.

Then we agree.

> After thinking about it, I think the suggested feature itself should
> probably be disabled under the restricted shell

Not our call to make. It's up to the system's administrator.
They could whitelist some libraries for restricted use.

> similar features such as `enable -f' and `command -p'
> are also disabled in the restricted shell.

The most similar feature at all is the source builtin
and it's not disabled, it's just restricted to file names
that don't contain slashes. Pure bash module managers
are just straight up incompatible with this if they depend
on the ability to pass an absolute file name to source.
The builtin option approach does not have this limitation.

> If it would be enabled, BASH_SOURCE_PATH should be
> at least readonly the same as PATH.

That feature will be in the v2 patch set
which I'm already preparing. 

> I think it's unrealistic to ensure all the existing codes
> that prepare restricted shells to be updated to care
> about BASH_SOURCE_PATH before Bash is updated

Restrictions are enforced after startup files are read.
In case of restricted shell, the libraries path could be
set to the empty string. That'd require the administrator
to explicitly whitelist a set of paths for source, avoiding
any potential problems.

> Of course the topic is different, but the logic is similar.

I'm just gonna accept that. Otherwise this will derail
into a discussion about XDG directories.

> I think they are still serious, but they don't have time to explain
> everything in detail.

The whole point of discussing things is to get those details though.

> Your statement "My only request here is that you seriously consider
> the work of a fellow software developer for merging into master.
> That's all." read like so.

I asked only that you read the patch and evaluate its merits.
At no point did I demand that it be merged.

Evaluating/criticizing the code? That's absolutely fine.
Not even reading the patch though?
That just signals I'm beneath your consideration.

> turned out that there are "refactorings"
> unrelated to the present purpose.

Yes, there are refactorings.
I moved some code around.
I turned hard coded strings into function parameters.

  -- Matheus

Re: [PATCH 4/9] bashgetopt: define long option shortener function

[Chet Ramey]

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 don't all have long options to begin with.
Is there a reason for it?


I don't think they're needed for builtins. --help is an extremely special
case.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH 0/4] Add import builtin

[Chet Ramey]

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 have achieved
consensus.



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.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH 0/4] Add import builtin

[Chet Ramey]

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
`source' builtin should also follow POSIX.


Because `.' and `source' have always been equivalent, and it will take a
better reason than this to change that.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH 4/9] bashgetopt: define long option shortener function

[Chet Ramey]

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 (1989),
`type' was the only builtin that supported any kind of long option;
no other builtins ever have.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH 0/4] Add import builtin

[Chet Ramey]

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 managers resolve the path
and pass in absolute file names, as you noted.


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.


The number of lines being 203 is definitely large.


Definitely large? I don't know about that.
I even split it up into logical changes.


It takes less than a dozen lines of code to implement BASH_SOURCE_PATH.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [sr #111058] Problem transmitting script arguments

[Dale R. Worley]

"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 I shouldn't have bothered), or that I should
have done so by some different method?

Dale

Re: [sr #111058] Problem transmitting script arguments

[Greg Wooledge]

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 does that mean that there is no way for me to effectively
> suggest a solution (and so I shouldn't have bothered), or that I should
> have done so by some different method?

Any replies you make here will go into the list archives, where someone
might find them if they search for this topic.  Maybe even the original
bug submitter, though the chances of that seem low, given that they
submitted this bug rather than searching for any existing literature
or discussions.

So, you just need to decide whether the time you'll spend writing a
reply here is justified.

Re: [sr #111058] Problem transmitting script arguments

[Kerin Millar]

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 there is no way for me to effectively
> suggest a solution (and so I shouldn't have bothered), or that I should
> have done so by some different method?

At is stands, the best that can be done is to click through to the applicable 
Savannah issue and directly comment there, in the hope that the person that 
opened the issue later returns to  check for any new comments. No account is 
required to do so. In this particular case, they did and were able to resolve 
their issue.

https://savannah.gnu.org/support/?111058

-- 
Kerin Millar

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

[Matheus Afonso Martins Moreira]

> 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 implementing
this as a change in bash, in contrast to implementing
it a an external function.

It's true that BASH_SOURCE_PATH would solve the problem
and it would be a very welcome change to the shell.
I will be very happy if support for that is added.

I also agree that the attempt to introduce a new builtin
was misguided and I have already abandoned it.
This email thread belongs to the first patch set I sent,
I followed up with a more conservative approach that
adds an option to the source builtin. I'm currently
preparing a v2 patch set which incorporates all
the feedback I've received.

> It takes less than a dozen lines of code
> to implement BASH_SOURCE_PATH.

The actual code implementing the feature
in the source builtin is in that range.
These are the changes I made which truly
implement the feature:

variables: define default BASH_LIBRARIES_PATH
config-top.h | 7 +++
variables.c  | 1 +
builtins/source: search libraries in library mode
builtins/source.def | 5 -

About half of the patch was just some reorganization.
I tried to make the code better as I went along,
so that the final implementation would be shorter.

Some of those changes had unintended consequences
such as exposing a function to builtins as an API.
Others were not desired such as long option support.
They will be dropped in the v2 patch set,
which will be much smaller.

  -- Matheus

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

[Matheus Afonso Martins Moreira]

> 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 behaves differently
depending on the state of the shell. The bash documentation
for the source builtin states:

> If filename does not contain a slash,
> the PATH variable is used to find filename,
> but filename does not need to be executable.

> When Bash is not in POSIX mode,
> it searches the current directory
> if filename is not found in $PATH.

I thought that simply adding the BASH_SOURCE_PATH 
variable would end up adding a new if statement to the
documentation. Something like:

> If the BASH_SOURCE_PATH environment variable
> is defined, bash will search for filename in the
> directories specified by it first, falling back to
> PATH if not found.

I interpreted that as adding complexity to the builtin
and sought to avoid it by taking another approach.
The result would be documented like this:

> If the -l option is passed, bash searches the directories
> specified by BASH_LIBRARIES _PATH only. PATH is ignored.

I thought that was simpler.

  -- Matheus

Re: [sr #111058] Problem transmitting script arguments

[Chet Ramey]

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 effectively
suggest a solution (and so I shouldn't have bothered), or that I should
have done so by some different method?


The notifications from savannah come with this text:

"Reply to this item at:

  "

and clicking the link will take you to the appropriate savannah issue
page, where you can add a comment. savannah is rather self-contained;
the notifications are so interested people can go to savannah and
contribute.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Re: [PATCH 4/9] bashgetopt: define long option shortener function

[Matheus Afonso Martins Moreira]

> 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