zimoun writes: > Hi again, :-) > > On Thu, 9 Jan 2020 at 13:55, Pierre Neidhardt wrote: > >> What I originally suggested is that we could equivalently do: >> >> guix search "/foo.*bar" python- > > [...] > >> > Time to time, I am looking for header C file or latex style but I do >> > not know the path. I would like to have something like: >> > >> > guix search gmsh.h >> > or >> > guix search ieee*.sty >> >> That's OK, if you know the basename then "/gmsh.h" will match. >> If you only know a substring of the basename, then "/.*gmsh.h" will >> match too. > > My point is just I do not like the key '/' to turn on the file-search > and I prefer "file:". As said elsewhere. :-) Why don't you like it? I don't like "file:" because: - It can make for ambiguous command line to the human read (e.g. "file:file:"). - It's a new arbitrary syntax which the user must learn to use it, which means they probably won't. The benefit of "/" is that it works _incidentally_. If you are looking for "bin/hg", then `guix search bin/hg` will do the right thing. > What is the purpose of this "list-files" for you? Listing the files of a package like in the example you gave. What I meant is that we already have a subcommand that outputs a property of the given packages, i.e. "guix size". If I'm not mistaken, there is no "guix package" flag that displays any property for the given packages. I am just thinking about keeping consistency across the various subcommands of Guix. -- Pierre Neidhardt https://ambrevar.xyz/