Zargs bug

Zargs bug

[Aryn Starr]

Hi!
I run this line:

$ zargs -t -i _ -- ceer whh -- compdef _=which
compdef ceer=which
compdef whh=which

But the completions don’t activate. When I manually run ‘compdef ceer=which’, though, it works flawlessly. 
Btw, these ceer and whh are just some functions I have defined.

PS: I’m not really familiar with using mailing lists, and I’m not on zsh mailing list. So reply to me directly? Also, should I reply to all in response?

Re: Zargs bug

[Stephane Chazelas]

2019-07-03 22:08:04 +0430, Aryn Starr:
> I run this line:
> 
> $ zargs -t -i _ -- ceer whh -- compdef _=which
> compdef ceer=which
> compdef whh=which
> 
> But the completions don’t activate. When I manually run
> ‘compdef ceer=which’, though, it works flawlessly. 
[...]

zargs runs the commands in a subshell, so they can't affect the
current shell environment.

Same as if you'd run:

(compdef ceer=which)

AFAICT, it's not documented but the code of zargs has:

# Everything has to be in a subshell just in case of backgrounding jobs,
# so that we don't unintentionally "wait" for jobs of the parent shell.

-- 
Stephane

Re: Zargs bug

[Aryn Starr]

I suggest adding an option flag for not using the subshell if it’s easy to do so. 
I currently reimplemented this application with this function:

rexa () {
        local i
        for i in "${@:2}"
        do
                eval "$(sed -e "s/_/${i:q:q}/g" <<< "$1")"
        done
}

It seems to be working.
> On Jul 3, 2019, at 10:35 PM, Stephane Chazelas <stephane.chazelas@gmail.com> wrote:
> 
> 2019-07-03 22:08:04 +0430, Aryn Starr:
>> I run this line:
>> 
>> $ zargs -t -i _ -- ceer whh -- compdef _=which
>> compdef ceer=which
>> compdef whh=which
>> 
>> But the completions don’t activate. When I manually run
>> ‘compdef ceer=which’, though, it works flawlessly. 
> [...]
> 
> zargs runs the commands in a subshell, so they can't affect the
> current shell environment.
> 
> Same as if you'd run:
> 
> (compdef ceer=which)
> 
> AFAICT, it's not documented but the code of zargs has:
> 
> # Everything has to be in a subshell just in case of backgrounding jobs,
> # so that we don't unintentionally "wait" for jobs of the parent shell.
> 
> -- 
> Stephane