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

[Koichi Murase]

2024年5月7日(火) 2:11 Matheus Afonso Martins Moreira <matheus@matheusmoreira.com>:
> >> 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_SOURCE_PATH. 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 to the version with the
suggested feature turned on. It will be a loophole under the practical
maintenance practice.

> > Much like the periodic requests for XDG-organized startup files
>
> I'd really appreciate it if my contribution wasn't regarded
> as just the latest iteration in the infinite loop of annoying
> XDG Base Directory implementation requests from users.

Of course the topic is different, but the logic is similar. It is
useful, but it can be implemented by shell functions. In such a case,
by default, I don't think such a feature should go into the codebase.
However, users seem to have special reasons in each case, while there
are also problems that are not solved by turning them from shell
functions to a built-in feature. Then, the discussion continues. The
structure is similar, yet the problems and reasons behind are totally
different.

> > If you avoid discussion by showing the relation with the authority,
> > it seems a proof of lacking a straightforward counter argument
>
> I avoided discussion because I started to feel like
> I wasn't being taken seriously. I was discussing
> the matter with you in good faith before that.

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

> I think that is easier for users to understand.
> It certainly is easier for me to understand.

Yeah, but if you change your mind and implement it differently, you
cannot stop new arising discussions about the change.

> > However, as far as I understand, no one has requested you
> > to work on this. You've voluntarily appeared on the help-bash and
> > bug-bash lists and submitted patches.
>
> Was this inappropriate?

This part is perfectly appropriate, though I felt some clumsiness.

> > It's unfair to request 100% merge
>
> I did not request that.

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.

> > The code change seems too large considering the amount of the feature
> > change, but I haven't yet checked the code. I'll later check them.
>
> Perhaps the number of patches gave everyone that impression.

Not only the number of patches, but also the number of lines. Then, it
turned out that there are "refactorings" unrelated to the present
purpose.

> The others could be cherry picked independently.

Maybe.