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

[Andrew Gregory]

On 10/27/15 at 08:27pm, Allan McRae wrote:
> On 27/10/15 20:10, Florian Pritz wrote:
> > On Sun, 25 Oct 2015 14:14:49 -0400 Andrew Gregory
> > <andrew.gregory.8 at gmail.com> wrote:
> >> On 10/25/15 at 05:07pm, Florian Pritz wrote:
> >>> Signed-off-by: Florian Pritz <bluewind at xinu.at>
> >>> ---
> >>>
> >>> v2:
> >>>  - Always output paths without leading slash
> >>>
> >>>  doc/pacman.8.txt    |  4 ++++
> >>>  src/pacman/conf.h   |  2 ++
> >>>  src/pacman/files.c  | 69 ++++++++++++++++++++++++++++++++++++++---------------
> >>>  src/pacman/pacman.c |  6 +++++
> >>>  4 files changed, 62 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
> >>> index 38b8bb7..1f11cf3 100644
> >>> --- a/doc/pacman.8.txt
> >>> +++ b/doc/pacman.8.txt
> >>> @@ -477,6 +477,10 @@ The '--list', '--search' and '--owns' options are exclusive and can not be combi
> >>>  *-o <file>, \--owns<file>*::
> >>>  	Search for packages that own a particular file.
> >>>  
> >>> +*--machinereadable*::
> >>> +	Use a machine readable output format for '--list', '--search' and
> >>> +	'--owns'. The format is 'repository/pkgname pkgver path'.  
> >>
> >> Spaces are not really reliable field separators.  Every single field
> >> being printed is allowed to contain spaces by alpm/pacman.
> > 
> > What is then? Best I see is that man PKGBUILD exclude hyphens for
> > pkgname, pkgver, pkgrel, but obviously it doesn't say anything about
> > repo names. I would not have expected a space to be allowed in those
> > though. Is that intentional or should we maybe exclude it too?
> > 
> 
> pkgname and pkgrel can not contain spaces according to makepkg. I
> believe pacman will handle packages with them just fine though.  pkgver
> works with a space.

makepkg may be the official method of building packages, but it is
certainly not the only way to build one, so I don't consider its
limitations particularly relevant here.  If the goal is to provide an
output format that programs can reliably parse it should work with the
full range of values supported by alpm/pacman.  alpm only restricts
<repo> to characters legal in a file name; they can even contain
newlines, although pacman doesn't support repos with newlines.
<pkgname> and <pkgver> are similarly limited to file-name-legal
characters, but they cannot contain newlines.  Paths can, of course,
contain any path-legal character except newlines.

If you want to provide this level of detail in a reliable
machine-readable format, the only characters you can rely on for
field/record separators are '/', '\n', and '\0'.

apg