Completion issue when zsh is not the default shell

Completion issue when zsh is not the default shell

[Julien Nicoulaud]

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

Hi,

On my work machine bash is the default shell (AD accounts...), and I have
an issue with the SSH completion:

ssh sto<TAB>bash: _ssh_hosts: command not found...

Trace file (see line 622): https://pastebin.com/raw/eE6XJbg2

It looks like at some point bash is invoked, which tries to resolve
_ssh_hosts and fails.

If I explicitly "autoload _ssh_hosts", it works correctly. It looks like a
bug to me ?

Cheers,
Julien

Re: Completion issue when zsh is not the default shell

[Peter Stephenson]

On Fri, 2018-10-26 at 16:25 +0200, Julien Nicoulaud wrote:
> On my work machine bash is the default shell (AD accounts...), and I have
> an issue with the SSH completion:
> 
> ssh sto<TAB>bash: _ssh_hosts: command not found...
> 
> Trace file (see line 622): https://pastebin.com/raw/eE6XJbg2
> 
> It looks like at some point bash is invoked, which tries to resolve
> _ssh_hosts and fails.
> 
> If I explicitly "autoload _ssh_hosts", it works correctly. It looks like a
> bug to me ?

It clearly shouldn't be running bash, but it's entirely unclear from
what you say why it actually is.  So I'm just having to guess.

Presumably _ssh_hosts is being found by your $path, rather than your
$fpath, so being executed as a command rather than function  It's not
clear why your system would be set up to find _ssh_hosts that way --- it
means your shell function directory is being searched for commands --- but
it's not actually a problem in general so long as the "autoload" has
been done.

Given that explicitly using "autoload" works, that means _ssh_hosts *is*
also being found along $fpath.

So the issue is it's not being marked for autoload automatically.  I can
think of a few reasons for this:

1. When "compinit" is run, $fpath isn't yet set up properly.  You'd
need to track this down in the initialisation sequence.  "compinit"
clearly is being run, or the shell wouldn't know about any association
between ssh completion _ssh_hosts.

2. You're hitting an old .zcompdump file that doesn't autoload this
but for some reason doesn't get detected as out of date.  This isn't
particularly likely but "rm ~/.zcompdump*" is an easy thing to try and
only incurs a one-off reload penalty.

3. There's an alternative _ssh_hosts early in your $fpath and it
doesn't contain the first line needed by the completion system,

#autoload

that you'll see in the file that comes with zsh.  This is probably my
top guess.  Have a look at

print -l $^fpath/_ssh_hosts(N)

(expand fpath to include any occurence of _ssh_hosts but remove any
entries that aren't matched as files).

pws

Re: Completion issue when zsh is not the default shell

[Julien Nicoulaud]

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

Thanks for the detailed answer !

Your second guess was the right one: deleting zcompdump solved the issue. I
suspect this is related to bytecode compilation, I have this snippet at the
end of my zshrc:
autoload -U zrecompile && zrecompile -p $MAIN_USER_HOME/.{zcompdump,zshrc}
&>/dev/null

So it also could be zrecompile failing to detect changes in zcompdump, I
guess ?

Unfortunately I deleted the files before thinking of checking the
modification times... The home partition is using xfs with options
rw,relatime,attr2,inode64,noquota, maybe there is a gotcha.


Le ven. 26 oct. 2018 à 17:02, Peter Stephenson <p.stephenson@samsung.com> a
écrit :

> On Fri, 2018-10-26 at 16:25 +0200, Julien Nicoulaud wrote:
> > On my work machine bash is the default shell (AD accounts...), and I have
> > an issue with the SSH completion:
> >
> > ssh sto<TAB>bash: _ssh_hosts: command not found...
> >
> > Trace file (see line 622): https://pastebin.com/raw/eE6XJbg2
> >
> > It looks like at some point bash is invoked, which tries to resolve
> > _ssh_hosts and fails.
> >
> > If I explicitly "autoload _ssh_hosts", it works correctly. It looks like
> a
> > bug to me ?
>
> It clearly shouldn't be running bash, but it's entirely unclear from
> what you say why it actually is.  So I'm just having to guess.
>
> Presumably _ssh_hosts is being found by your $path, rather than your
> $fpath, so being executed as a command rather than function  It's not
> clear why your system would be set up to find _ssh_hosts that way --- it
> means your shell function directory is being searched for commands --- but
> it's not actually a problem in general so long as the "autoload" has
> been done.
>
> Given that explicitly using "autoload" works, that means _ssh_hosts *is*
> also being found along $fpath.
>
> So the issue is it's not being marked for autoload automatically.  I can
> think of a few reasons for this:
>
> 1. When "compinit" is run, $fpath isn't yet set up properly.  You'd
> need to track this down in the initialisation sequence.  "compinit"
> clearly is being run, or the shell wouldn't know about any association
> between ssh completion _ssh_hosts.
>
> 2. You're hitting an old .zcompdump file that doesn't autoload this
> but for some reason doesn't get detected as out of date.  This isn't
> particularly likely but "rm ~/.zcompdump*" is an easy thing to try and
> only incurs a one-off reload penalty.
>
> 3. There's an alternative _ssh_hosts early in your $fpath and it
> doesn't contain the first line needed by the completion system,
>
> #autoload
>
> that you'll see in the file that comes with zsh.  This is probably my
> top guess.  Have a look at
>
> print -l $^fpath/_ssh_hosts(N)
>
> (expand fpath to include any occurence of _ssh_hosts but remove any
> entries that aren't matched as files).
>
> pws
>
>
>

Re: Completion issue when zsh is not the default shell

[Phil Pennock]

On 2018-10-26 at 20:49 +0200, Julien Nicoulaud wrote:
> suspect this is related to bytecode compilation, I have this snippet at the
> end of my zshrc:
> autoload -U zrecompile && zrecompile -p $MAIN_USER_HOME/.{zcompdump,zshrc}
> &>/dev/null

My understanding is that << zrecompile -p FOO >> passes FOO through as
arguments to zcompile, so you're invoking:

  zcompile $MAIN_USER_HOME/.zcompdump $MAIN_USER_HOME/.zshrc

which is the "zcompile file [ name ... ]" form, so you're compiling
.zshrc into the file .zcompdump (instead of .zshrc.zwc).

I think that just removing the "-p" should work.  (But I've not tried to
reproduce your breakage).


What happens if fpath is broken and zrecompile can't be autoloaded?
What if you fixed such a breakage in .zshrc, but you're not recompiling
and the old fpath is still being used from the binary file, even while
the source files are correct?

This should be "zsh -e" safe, while still giving you more clues what's
failing if things fail:

if ! autoload -U zrecompile ; then
  print -u2 ".zshrc: warning: failed to autoload zrecompile, is fpath okay?'
else
  zrecompile $MAIN_USER_HOME/.{zcompdump,zshrc} || ev=$?
  if (( ev )); then
    print -u2 ".zshrc: warning: zrecompile failed, exiting $ev"
  fi
fi

Re: Completion issue when zsh is not the default shell

[Julien Nicoulaud]

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

Thanks,

I completely missed that, I should have RTFM better (as always) :)

For what it's worth, I ended up with:

autoload -U zrecompile && zrecompile -p $MAIN_USER_HOME/.zshenv -- \
                                        $MAIN_USER_HOME/.zshrc -- \
                                        $MAIN_USER_HOME/.profile -- \
                                        $MAIN_USER_HOME/.zcompdump \
                                        1>/dev/null

Which will only print messages if these files are missing or byte
compilation fails.

Le dim. 28 oct. 2018 à 05:20, Phil Pennock <
zsh-workers+phil.pennock@spodhuis.org> a écrit :

> On 2018-10-26 at 20:49 +0200, Julien Nicoulaud wrote:
> > suspect this is related to bytecode compilation, I have this snippet at
> the
> > end of my zshrc:
> > autoload -U zrecompile && zrecompile -p
> $MAIN_USER_HOME/.{zcompdump,zshrc}
> > &>/dev/null
>
> My understanding is that << zrecompile -p FOO >> passes FOO through as
> arguments to zcompile, so you're invoking:
>
>   zcompile $MAIN_USER_HOME/.zcompdump $MAIN_USER_HOME/.zshrc
>
> which is the "zcompile file [ name ... ]" form, so you're compiling
> .zshrc into the file .zcompdump (instead of .zshrc.zwc).
>
> I think that just removing the "-p" should work.  (But I've not tried to
> reproduce your breakage).
>
>
> What happens if fpath is broken and zrecompile can't be autoloaded?
> What if you fixed such a breakage in .zshrc, but you're not recompiling
> and the old fpath is still being used from the binary file, even while
> the source files are correct?
>
> This should be "zsh -e" safe, while still giving you more clues what's
> failing if things fail:
>
> if ! autoload -U zrecompile ; then
>   print -u2 ".zshrc: warning: failed to autoload zrecompile, is fpath
> okay?'
> else
>   zrecompile $MAIN_USER_HOME/.{zcompdump,zshrc} || ev=$?
>   if (( ev )); then
>     print -u2 ".zshrc: warning: zrecompile failed, exiting $ev"
>   fi
> fi
>
>