Command wrappers in $PATH, and re-executing the "correct" value

Command wrappers in $PATH, and re-executing the "correct" value

[Zach Riggle]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

I find that very frequently I write a wrapper for some CLI tool, say
"foobar".

Let's say lives at e.g. /usr/local/bin/foobar, and $path is ( ... ~/bin ...
/usr/local/bin ).

I have a wrapper script ~/bin/foobar, which will be invoked for the command
"foobar".  What my wrapper script does is immaterial, but it eventually
executes the /usr/local/bin/foobar with some set of arguments.

As best I can tell, there are three ways to make this work neatly:

   - Implement "my" foobar as a function, and use "command foobar"
      - How do I make this an autoloadable module, which doesn't need to
      use e.g.
      "autoload foobar && foobar"
   - Remove ~/bin from $path, and add it to the end
      - This might break other things where system binaries take over
   - Some cool tricks with /usr/bin/env and such I haven't thought of

I've already adopted autoloadable functions via $fpath and using "command
foobar" inside the function, but I was curious if there's another way.  I
expect that removing ${0:h} and ${0:A:h} from $path are the most obvious
answers, but I didn't know if there's anything easier.

*Zach Riggle*

[-- Attachment #2: Type: text/html, Size: 1535 bytes --]

Re: Command wrappers in $PATH, and re-executing the "correct" value

[Roman Perepelitsa]

On Sat, May 21, 2022 at 8:30 AM Zach Riggle <zachriggle@gmail.com> wrote:
>
> I find that very frequently I write a wrapper for some CLI tool, say "foobar".
>
> I have a wrapper script ~/bin/foobar, which will be invoked for the
> command "foobar".  What my wrapper script does is immaterial, but
> it eventually executes the /usr/local/bin/foobar with some set of
> arguments.

You can try this:

    #!/usr/bin/zsh
    #
    # usage: next-command <command> [arg]..

    path=(${path:#${commands[$1]:h}}) "$@"

Put this in a file named next-command somewhere in PATH. Then invoke
it as `next-command foobar` from within foobar or from anywhere else.
Nice things about this solution:

- It's a script rather than an alias or a function, so it can be
invoked from anywhere.
- You can peel several levels of wrappers.

Bad things about it:

- If /usr/local/bin/foobar invokes baz, which is supposed to resolve
as ~/bin/baz, it won't be found (or perhaps will be found in a
different directory).

Roman.

Re: Command wrappers in $PATH, and re-executing the "correct" value

[Mikael Magnusson]

On 5/21/22, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> On Sat, May 21, 2022 at 8:30 AM Zach Riggle <zachriggle@gmail.com> wrote:
>>
>> I find that very frequently I write a wrapper for some CLI tool, say
>> "foobar".
>>
>> I have a wrapper script ~/bin/foobar, which will be invoked for the
>> command "foobar".  What my wrapper script does is immaterial, but
>> it eventually executes the /usr/local/bin/foobar with some set of
>> arguments.
>
> You can try this:
>
>     #!/usr/bin/zsh
>     #
>     # usage: next-command <command> [arg]..
>
>     path=(${path:#${commands[$1]:h}}) "$@"

I'm using this in mine (wrapper script of same name as target binary),
path[(R)$0:h]=() exec $0:t "$@"

-- 
Mikael Magnusson

Re: Command wrappers in $PATH, and re-executing the "correct" value

[Roman Perepelitsa]

On Sat, May 21, 2022 at 9:20 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 5/21/22, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> >
> >     path=(${path:#${commands[$1]:h}}) "$@"
>
> I'm using this in mine (wrapper script of same name as target binary),
> path[(R)$0:h]=() exec $0:t "$@"

There is a difference in behavior if the wrapper directory is listed
in PATH more than once. My version removes all of them, while yours
removes only the **last** instance. I can see a point being made for
removing the **first** but removing the last seems wrong. Is this
intended?

Roman.