Hi Diego, Diego Nicola Barbato <dnbarb...@posteo.de> skribis:
> Ludovic Courtès <l...@gnu.org> writes: > >> Diego Nicola Barbato <dnbarb...@posteo.de> skribis: >> >>> Ludovic Courtès <l...@gnu.org> writes: >> >> [...] >> >>>> In addition, be aware that Bash maintains a cache of commands it looked >>>> up in $PATH. Thus it may be that, say, it had cached that ‘guix’ is >>>> really /run/current-system/profile/bin/guix. When you pulled, it didn’t >>>> invalidate its cache thus you kept using that old version. >>>> >>>> The solution is to run “hash guix” at the Bash prompt to force cache >>>> invalidation (info "(bash) Bourne Shell Builtins"). >>> >>> I believe this is it. This also explains why ‘which guix’ returned the >>> updated guix while ‘guix --version’ claimed it was still the older >>> version, which I found rather confusing. >>> I am afraid being unaware of this has led me to inadvertently downgrade >>> GuixSD whenever I reconfigured for the first time after a fresh install. >> >> Yeah. This is not strictly speaking a Guix bug, but clearly it’s a >> common pitfall. Perhaps we should print a hint upon completion? > > While I think it would be nice for Guix (or strictly speaking Bash) to > just do what a noob like me would expect it to do in this situation, a > hint would have certainly saved me some trouble. If it is unreasonably > cumbersome to make Guix tell Bash to invalidate its cache upon > completion of ‘guix pull’, I believe a hint would be good enough. Thanks for the heads-up. Commit 3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display a hint in this case. Ludo’.
