GNU bug report logs -
#33647
First `guix pull' behaves unexpectedly
Previous Next
Full log
Message #44 received at 33647-done <at> debbugs.gnu.org (full text, mbox):
Hi Diego,
Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:
>>
>>> Ludovic Courtès <ludo <at> 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’.
This bug report was last modified 6 years and 180 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.