Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Koichi Murase]

2024年5月24日(金) 19:18 Martin D Kealey <martin@kurahaupo.gen.nz>:
> On Tue, 21 May 2024 at 23:16, Koichi Murase <myoga.murase@gmail.com> wrote:
>> 2024年5月21日(火) 14:56 Phi Debian <phi.debian@gmail.com>:
>> > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't
>> > know if that would be good enough for the initial purpose.
>>
>> There are already shell-function implementations at
>> /examples/functions/autoload* in the Bash source. They reference FPATH
>> to load functions, though one needs to call `autoload' for each
>> function in advance (by e.g. `autoload "$fpath_element"/*' ).
>
> My solution to this was to call 'autoload --all', which would gather all the
> filenames in FPATH (*1) and create autoload stubs for them.

Thank you for your comments.

These were just a comment on the implementations /example/functions/autoload*,
but yeah, I haven't noticed that `autoload.v4' actually supports the equivalent
option `autoload -f'.  If you would define your own `autoload', of course, you
can define the useful feature.

I think there is still a minor (and maybe negligible?) issue when a new path is
added to FPATH after performing `autoload --all'.  One would need to
additionally call `autoload "$fpath_added_element"/*' (or one could run
`autoload --all' again, but this would scan all the directories that were
already processed).

> Alternatively one could define a commandnotfound function to defer this until
> actually needed.

I thought about it before, but `command_not_found_handle' is executed in a
subshell, so the loaded functions will not be reflected in the original shell
process.

> (*1 I actually used a different variable name, since I wasn't providing
> exactly the same semantics as ksh, but that's relatively cosmetic)

I intended to talk about the specific semantics of ksh93/zsh's FPATH, but if we
extend the discussion to different variable names and different semantics, I
actually have my own `autoload' [1] referring the variable
`bleopt_import_path', where the function names are specified to `autoload' with
an explicit module name defining them.  An example use is found in
e.g. Ref. [2], although the module is specified by an absolute path in this
case.

[1] 
https://github.com/akinomyoga/ble.sh/blob/b72d78a97e6867bbf43de6a645dd6e387525443f/src/util.sh#L5071
[2] 
https://github.com/akinomyoga/ble.sh/blob/b72d78a97e6867bbf43de6a645dd6e387525443f/lib/core-syntax-def.sh#L62-L79

>> However, I personally do not think the FPATH mechanism is useful
>> because a file can only contain one function per file. Significantly
>> non-trivial functions are usually implemented by a set of helper
>> functions or sub-functions.
>
> Defining extra (private) functions in a file loaded from FPATH does no harm,
> as long as its name doesn't conflict.

I was assuming the Zsh's implementation of $FPATH.  I thought the Zsh
implementation of $FPATH doesn't allow it, but I now learned that ksh's
implementation of $FPATH is different.  I'm not a user of Zsh, so maybe I miss
something, but Zsh's default autoload assumes that each file contains the
*body* of the function (instead of the function declaration).  So if one puts a
set of functions in a file `func':

  internal1() { ...; }; internal2() { ...; }; func() { ...; }

and registers it through `autoload -U func', it would result in a big function
containing function definitions:

  func() { internal1() { ...; }; internal2() { ...; }; func() { ...; }; }

This is not an expected one.  However, TIL one can put function definitions in
ksh's style, and ksh's style can be used also in Zsh with `autoload -Uk func'.

>> Also, in libraries, we usually have a set
>> of functions that are closely related to one another and share the
>> implementations. I don't think it is practical to split those
>> functions into dozens or hundreds of files.
>
> I would hesitate to call what I've done "a manager", but my approach has been
> to allow a file to "declare" all the public functions it defines, and then
> simply have symlinks (or even hard links) to a single underlying file.

OK, this should work as ksh's FPATH implementation allows including function
definitions.

In that sense, this is just my personal preference, but I prefer to prepare a
`header' script file (such as [2]) that contains `autoload' declarations and is
intended to be sourced on the initialization stage instead of creating as many
symbolic links as the public functions.

--
Koichi