* Completion issue when zsh is not the default shell @ 2018-10-26 14:25 ` Julien Nicoulaud 2018-10-26 14:55 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Julien Nicoulaud @ 2018-10-26 14:25 UTC (permalink / raw) To: Mailing-list zsh-users [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion issue when zsh is not the default shell 2018-10-26 14:25 ` Completion issue when zsh is not the default shell Julien Nicoulaud @ 2018-10-26 14:55 ` Peter Stephenson 2018-10-26 18:49 ` Julien Nicoulaud 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2018-10-26 14:55 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion issue when zsh is not the default shell 2018-10-26 14:55 ` Peter Stephenson @ 2018-10-26 18:49 ` Julien Nicoulaud 2018-10-28 4:20 ` Phil Pennock 0 siblings, 1 reply; 5+ messages in thread From: Julien Nicoulaud @ 2018-10-26 18:49 UTC (permalink / raw) To: p.stephenson; +Cc: Mailing-list zsh-users [-- 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 > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion issue when zsh is not the default shell 2018-10-26 18:49 ` Julien Nicoulaud @ 2018-10-28 4:20 ` Phil Pennock 2018-10-30 15:19 ` Julien Nicoulaud 0 siblings, 1 reply; 5+ messages in thread From: Phil Pennock @ 2018-10-28 4:20 UTC (permalink / raw) To: Julien Nicoulaud; +Cc: Mailing-list zsh-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion issue when zsh is not the default shell 2018-10-28 4:20 ` Phil Pennock @ 2018-10-30 15:19 ` Julien Nicoulaud 0 siblings, 0 replies; 5+ messages in thread From: Julien Nicoulaud @ 2018-10-30 15:19 UTC (permalink / raw) To: zsh-workers+phil.pennock; +Cc: Mailing-list zsh-users [-- 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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-10-30 15:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20181026142713epcas1p2bcbd7c6efff6d9e809fdbedb51eb6eba@epcas1p2.samsung.com> 2018-10-26 14:25 ` Completion issue when zsh is not the default shell Julien Nicoulaud 2018-10-26 14:55 ` Peter Stephenson 2018-10-26 18:49 ` Julien Nicoulaud 2018-10-28 4:20 ` Phil Pennock 2018-10-30 15:19 ` Julien Nicoulaud
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).