[pacman-dev] [PATCH v3 2/2] Add -F --machinereable option

Andrew Gregory andrew.gregory.8 at gmail.com
Fri Oct 30 19:08:06 UTC 2015


On 10/30/15 at 07:32pm, Florian Pritz wrote:
> On Fri, 30 Oct 2015 13:59:53 -0400 Andrew Gregory
> <andrew.gregory.8 at gmail.com> wrote:
> > Aside from a few style nitpicks, the code looks fine.  I am curious as
> > to the motivation for this though.  Most of our operations are made
> > easier to parse by using --quiet to reduce the output to a single
> > field.  Do you have a use case in mind for this that wouldn't be taken
> > care of by adding a --quiet option to -F or intend to add
> > --machinereadable to other operations?
> 
> Depending on what you want at least -Fs produces some very hard to
> parse output as you can see here:
> 
> > src/pacman/pacman -Fs makepkg
> core/pacman 4.2.1-4
>     usr/bin/makepkg
>     usr/share/bash-completion/completions/makepkg
> community/libreoffice-extension-texmaths 0.41-2
>     usr/lib/libreoffice/share/extensions/texmaths/makepkg
> community/plan9port 20150629-1
>     usr/lib/plan9/.git/logs/refs/heads/makepkg
>     usr/lib/plan9/.git/refs/heads/makepkg
> 
> -Fqs is easier to parse but provides only very limited information:
> 
> > src/pacman/pacman -Fqs makepkg
> core/pacman
> community/libreoffice-extension-texmaths
> community/plan9port
> 
> Also the format is not consistent across -F operations so any code that
> parses one format can not be used for the others which seems
> unnecessary.
> 
> I brought this up when Allan created the feature and he asked me to
> create a dedicated switch so I did. If you know of any operations that
> could benefit from such an option I might consider implementing it,
> however, expac already covers most of the normal stuff and I don't
> know if pacman can do a better job there. I certainly can with the -F
> operations.
> 
> I fixed the style issues and the subject typo mentioned by Pierre in my
> branch.

It is certainly true that getting detailed information out of pacman
in a way that's easy to parse is non-trivial.  But, that's true across
all of our operations.  Really, very little of pacman's output can be
reliably parsed without --quiet and I doubt anybody who isn't a pacman
developer would know all of the caveats to do so (even our own scripts
are unreliable).

My personal preference would be for people to use --quiet (which needs
to be added to -Fh BTW) and separately request any additional detail
they need.  But, maybe adding this will get people to stop trying to
parse output that is not meant to parsed, so I'm neutral on this
change.  If we do go this route though, I'd like to see it implemented
for other operations (the other --search operations are the most
obvious candidates), but that doesn't need to be part of this patch,
of course.

apg


More information about the pacman-dev mailing list