GNU bug report logs - #62264
[PATCH] Add 'guix locate' command

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: "Antoine R . Dumont" <antoine.romain.dumont <at> gmail.com>, 62264 <at> debbugs.gnu.org
Subject: [bug#62264] [PATCH] Add 'guix locate' command
Date: Sun, 18 Jun 2023 23:51:10 +0200

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>>> After deleting ~/.cache/guix/locate and cd’ing out of my home directory,
>>> then inside “guix shell -CW coreutils”, “guix locate ls” does not find
>>> ls.
>>
>> Works for me:
>>
>> $ guix shell -CW -D guix
>> […]
>> Note that ‘-W’ has the effect of sharing ~/.cache with the container.
>> That means that the database is already there.
>
> Ah of course that is why it works for you.  I had deleted the locate
> directory of the cache, so after `guix shell -CW -D guix` the `guix
> locate ls` did not work, and did not work either once I had left the
> container, because an empty database had been created in the cache from
> within the container.  Without -CW it works fine.  It is a minor bug.

Oh right, makes sense (not really a bug in the sense that the ‘profiles’
method just doesn’t find any profile from within ‘guix shell -CW’.)

>>> When I use “guix locate icecat”, it legitimately also locates a file
>>> lib/icecat/icecat in addition to the desired bin/icecat.  I try to
>>> filter by “guix locate bin/icecat” or “guix locate -g bin/icecat”, but
>>> it seems locate does not support file names with slashes.
>> Right: ‘guix locate’ only checks the “basename”; it does not let you
>> search on the absolute file name.  We could add an option to do that
>> later (say ‘-f’) but I thought it’s less frequently useful.
>
> I’m nitpicking, but if relative file names are not meant to be
> supported, could you change the doc/guix.texi at
>
> +@example
> +guix locate [@var{options}@dots{}] @var{file}@dots{}
> +@end example
> +
> +@noindent
> +... where @var{file} is the name of a file to search for.
>
> to reflect that FILE must be the basename?  Because in other parts of
> the doc, the term path is avoided and the term filename is used.  Now a
> filename is only a basename all of a sudden.

Yeah, it’s ambiguous: “file name” is generic and applies equally to a
“basename” and to a “fully-qualified name”.

I’ve hopefully clarified this in the manual and pushed the result as
bf9afedef9c55aa0092b562077d9f2c743d9a29c.

Thank you, and again thanks a lot Antoine for giving the initial
impulse!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.