Error upon starting zsh after upgrading

[casept]

I recently upgraded hishtory using the built-in hishtory upgrade command. Since then, I've been seeing the following message upon starting a shell:

/usr/bin/which: no compdef in (/home/casept/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/home/casept/.cargo/bin:/home/casept/x-tools/arm-unknown-linux-uclibcgnueabi/bin://home/casept/.pyenv/bin:/home/casept/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/lib64/ccache:/home/casept/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/casept/bin:/home/casept/usr/bin:/home/casept/.cargo/bin:/home/casept/go/bin:/home/casept/.local/bin/:/home/casept/.hishtory)

Hishtory seems to work fine despite the error, it's just a bit annoying.

On my other machines (where I've compiled hishtory from source instead of using the installer, in case that matters) this error doesn't occur. All machines share the same set of dotfiles, hosted at https://github.com/casept/dotfiles.

[ddworken]

Thank you for opening this issue! That is interesting that which maps to /usr/bin/which (rather than a shell built-in) and that it outputs that despite me attempting to silence the output of which. Can you share any more details on your OS and zsh version so I can take a deeper look at this? I'm guessing it is something nix specific, so I think I'll have to finally get around to giving nix a try. :)

[casept]

I don't think that the presence of Nix matters, as neither ZSH nor which is installed using it, it justs exists in my PATH.

The distro is a Fedora 39 with KDE.

which version info:

➜  ~ which --version
GNU which v2.21, Copyright (C) 1999 - 2015 Carlo Wood.
GNU which comes with ABSOLUTELY NO WARRANTY;
This program is free software; your freedom to use, change
and distribute this program is protected by the GPL.

zsh version info:

➜  ~ zsh --version
zsh 5.9 (x86_64-redhat-linux-gnu)

[casept]

After running another update, the message is now printed twice.

[ddworken]

Thank you for your patience and the helpful debugging info! b395f6f should take care of this. Once it finishes running tests on Github Actions, I'll get it released and re-ping this issue.

[casept]

Thank you for the fix!

I can confirm that the message is no longer printed. However, something still fails in the background and causes each new shell prompt to indicate that a command just failed (the output of echo $? right after starting a new shell is 1). Maybe you also need to ignore the exit code of some command?

[ddworken]

Thank you again for all the feedback! I just released 786d254 which fixes that too. :) Please let me know if there is anything else you spot.

[casept]

Seems like everything is fixed, thanks :+1: