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

[Koichi Murase]

2024年5月25日(土) 8:45 Lawrence Velázquez <vq@larryv.me>:
> On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote:
> > 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:
> >>> 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.
> >
> > [...] 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.
>
> Moving the extra "func" call into the definition itself takes that
> off the caller's hands [...]
>
>         % cat /tmp/func
>         internal1() { echo internal1 }
>         internal2() { echo internal2 }
>         func() { internal1; internal2 }
>         func

I thought we couldn't include multiple public functions and create
symbolic links that way.

However, I now tried $funcstack, and it seems to be working:

  internal1() { echo i1; }
  internal2() { echo i2; }
  public1() { printf p1; (($#)) && printf '<%s>' "$@"; echo; internal1; }
  public2() { printf p2; (($#)) && printf '<%s>' "$@"; echo;
internal1; internal2; }
  $funcstack[1] "$@"

> while maintaining the ability to use "func"
> as a standalone script (the motivation for the zsh style).

I see, I was wondering about the motivation.

--
Koichi