From: Diego Nicola Barbato <dnbarbato@posteo.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 33647@debbugs.gnu.org
Subject: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 13:49:17 +0100 [thread overview]
Message-ID: <87y38lu1f6.fsf@GlaDOS.home> (raw)
In-Reply-To: <87r2eth3by.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 07 Dec 2018 14:30:09 +0100")
Hello,
Ludovic Courtès <ludo@gnu.org> writes:
> Diego Nicola Barbato <dnbarbato@posteo.de> skribis:
>
>> Ludovic Courtès <ludo@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.
Greetings,
Diego
next prev parent reply other threads:[~2018-12-19 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-06 14:56 bug#33647: First `guix pull' behaves unexpectedly Diego Nicola Barbato
2018-12-06 15:42 ` Ricardo Wurmus
2018-12-06 17:03 ` Diego Nicola Barbato
2018-12-06 23:06 ` Ludovic Courtès
2018-12-07 8:36 ` Diego Nicola Barbato
2018-12-07 9:41 ` Björn Höfling
2018-12-07 13:30 ` Ludovic Courtès
2018-12-19 12:49 ` Diego Nicola Barbato [this message]
2018-12-19 17:37 ` swedebugia
2018-12-19 19:27 ` Tobias Geerinckx-Rice
2018-12-20 5:24 ` swedebugia
2019-01-18 16:54 ` Ludovic Courtès
2019-01-22 22:07 ` Diego Nicola Barbato
2019-01-23 9:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y38lu1f6.fsf@GlaDOS.home \
--to=dnbarbato@posteo.de \
--cc=33647@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.