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 >> <[email protected]> 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
