From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Package file indexing Date: Thu, 9 Jan 2020 14:53:34 +0100 Message-ID: References: <20190314204941.GA21065@jasmine.lan> <87mulx9kuv.fsf@nckx> <87zhpx846u.fsf@ambrevar.xyz> <87bm21y2s2.fsf_-_@gnu.org> <87imw7cpe7.fsf@bababa.i-did-not-set--mail-host-address--so-tickle-me> <87pnqdhkpf.fsf@gnu.org> <87imlt3hr2.fsf@ambrevar.xyz> <462f35f7596f7318d2b34cc300a7e27a69d2072c.camel@riseup.net> <87pnfs9437.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40239) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipYFv-0001uk-NU for guix-devel@gnu.org; Thu, 09 Jan 2020 08:53:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipYFu-0002s5-BE for guix-devel@gnu.org; Thu, 09 Jan 2020 08:53:47 -0500 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]:44683) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ipYFu-0002qu-3o for guix-devel@gnu.org; Thu, 09 Jan 2020 08:53:46 -0500 Received: by mail-qk1-x730.google.com with SMTP id w127so5952476qkb.11 for ; Thu, 09 Jan 2020 05:53:46 -0800 (PST) In-Reply-To: <87pnfs9437.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel Hi Pierre, On Thu, 9 Jan 2020 at 14:01, Pierre Neidhardt wrote: > > zimoun writes: > >> To avoid confusion, I think this should be an option/subcommand of > >> search. Something like -path and -name in find(1). > > > > I agree that explicit keywords, e.g., "file:" and "package:", avoid confusion. > > I disagree. What about matching a path which contains "file:" or > "package:"? Then you end up with confusing commands. About "file:", no issue: guix search file:file: However, yes there is an ambiguous behaviour of: guix search package: Currently, the command guix search returns an error. Does "guix search package:" return an error as "guix search"? Meaning search about 'empty'. Or does it return the packages matching the term "package:"? For example the package "perl-package-stash-xs" containing "Package:" in its description or the package "r-vctrs" containing "package:" in its description too. Note it is the only two packages. For backward compatibility, the ambiguity needs to be fixed by the latter. > Using "/" as a filter makes sense because it's the only character that's > not allowed in filenames (with \0) and it's safe to assume that it's not > useful to match against "/" in description / synopsis. > > Simon, regarding your examples: > > > - guix search bin/gmsh gimp > > - guix search file:ieee*.sty bin/gmsh latex > > - guix search file:bin/gmsh > > why mixing both the "file:" prefix and the "/"? Yes, I am suggesting to mix both. I would like to have all this syntax: > - guix search file:gmsh.h gimp > - guix search bin/gmsh gimp > - guix search file:ieee*.sty bin/gmsh latex > - guix search file:bin/gmsh > - guix search package:gimp Now, if we speak about the "search" command-line syntax, today the way is to write a regexp and then to filter with 'recsel'. It is UNIX philosophy to compose via pipes but the drawback is: one *has to* first (read the Guix manual [1] to) know the existence of 'recsel' and second read the documentation of 'recutils' for complex filtering. So, long time ago, I was thinking to add more syntax [2]. Today, the syntax is: guix search "" | recsel -C -e 'name ~ "agda" && !(name ~ "mode")' -p synopsis and I find more welcoming something avoiding the pipe, e.g., guix search 'name ~ "agda" && !(name ~ "mode") -p synopsis' Cheers, simon [1] http://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#Invoking-guix-package [2] https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00480.html