2024年5月25日(土) 8:45 Lawrence Velázquez <[email protected]>:
> On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote:
> > 2024年5月24日(金) 19:18 Martin D Kealey <[email protected]>:
> >> On Tue, 21 May 2024 at 23:16, Koichi Murase <[email protected]> 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
