all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

  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.