Hi
On +2020-07-09 11:25:05 +0200, zimoun wrote:
Toggle quote (20 lines)
> Dear,
>
> +Pierre because I am not sure he reads carefully debuugs. ;-)
>
> On Thu, 09 Jul 2020 at 10:13, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:
> > Serverity: wishlist
> > I often find myself checking the content of a package. For this I
> > would like to be able to inspect the list of files in a package, or
> > even query for a specific file.
>
> Pierre proposed "guix filesearch" some time ago.
>
> https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html
>
>
> > This is much like Debian does in "list of files" for each package (e.g. <https://packages.debian.org/en/buster/amd64/ejabberd-mod-cron/filelist>) and with "Search the contents of packages" <https://www.debian.org/distrib/packages#search_contents>
>
> Yes, it could be nice to have that in the Data Service.
>
Since this is about listing files, seems like it wouldn't be that hard to provide
a file globbing selection option like find dir -iname globexpr (pass through to find itself?)
(hm, also -newerct timespec can be a handy find opt)
and/or output control like "stat -c 'formatstring'" (likewise pass through to stat) ?
Also, ls-borrowed options like -B -1 -d -A might be nice.
If you want to consider the general problem of inspecting arbitrary object component details,
lsblk -o,selected,fields,listed,here might be a good model (including -n option).
I think it would be nice if all object detail listing functions would converge in design
to a few consistent ways of specifying source and output options, so we wouldn't have
to re-invent "$(foo -dumpalot|sed -E ad_hoc_hack)" so much.
Are there any system design guidelines for converging?
BTW, please preserve cli and info retrieval independence from GUI systems,
(except when GUI preferences and parameters are the objects being inspected,
of course, but even then, minimize entanglements :)
