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

[Allan McRae]

On 31/10/15 05:08, Andrew Gregory wrote:
> 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.
> 

I saw this as something that could be expanded in the future, so adding
to -F was a first step.

A