On 27/10/15 20:10, Florian Pritz wrote:
On Sun, 25 Oct 2015 14:14:49 -0400 Andrew Gregory <andrew.gregory.8@gmail.com> wrote:
On 10/25/15 at 05:07pm, Florian Pritz wrote:
Signed-off-by: Florian Pritz <bluewind@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.
@@ -222,8 +243,14 @@ static int files_list(alpm_list_t *syncs, alpm_list_t *targets) {
if((pkg = alpm_db_get_pkg(db, targ)) != NULL) { found = 1; - dump_file_list(pkg); - break; + if(config->op_f_machinereadable) { + dump_pkg_machinereadable(db, pkg); + // list all repos if not asked for a specific one
I don't like having the machine readable format printing a different set of packages than the normal format.
My format includes the repo so a user can easily tell when lines appear multiple times why that happens while this is not possible with the normal format. I don't care too much about this though. Allan, Dave?
I'm failure sure I said the same as Andrew with an earlier iteratino on IRC earlier.
+ continue;
Unnecessary continue.
Given the else uses break it seems more readable to be me include the continue so that the intention is clear. Allan, Dave?
I've fixed the other stuff you mentioned and will send a new patch once the questions above are cleared.
Not needed anyway if only one package is printed. A