Re: readlink(1) of more than one file?

[Pádraig Brady]

On 12/15/2012 03:09 PM, Bernhard Voelker wrote:
> On 12/15/2012 02:54 AM, Pádraig Brady wrote:
>
> >  From 4217f8a0fc62fa142752e8fc57cd3824ee7b7641 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?P=C3=A1draig=20Brady?= <address@hidden>
> > Date: Wed, 12 Dec 2012 19:54:12 +0000
> > Subject: [PATCH] readlink: support multiple command line arguments
> >
> > This allows efficient processing of processing multiple files,
>
> s/processing of processing/processing of/

good one.

> > +++ b/NEWS
> > @@ -61,6 +61,8 @@ GNU coreutils NEWS                                    -*- 
> > outline -*-
> >
> >   ** Improvements
> >
> > +  readlink now supports multiple arguments.
> > +
>
> I think that also --zero should be mentioned in NEWS.

I always try to keep NEWS concise,
but you're right in this case.

> > +++ b/tests/readlink/multi.sh
> > [...]
> > +readlink -m --zero /1 /1 > out
>
> Jim has mentioned already that a "|| fail=1" should be added
> after each test. I want to propose - in retrospective of the recent
> "cp --no-preserve=mode" bug (#13119) - that we maybe should add
> a new syntax-check rule to enforce such exit code checking.

That would be difficult to impossible to construct I expect.
For the record I adjusted the test like:

-printf "/1\0/1\0" > exp
-readlink -m --zero /1 /1 > out
+printf "/1\0/1\0" > exp || framework_failure_
+readlink -m --zero /1 /1 > out || fail=1

>    $ src/readlink --help
>    Usage: src/readlink [OPTION]... FILE...
>    Print value of a symbolic link or canonical file name
>
> Shouldn't man/readlink.x also be adapted?

Very good spot. I also notice we should reference realpath here, so:

diff --git a/man/readlink.x b/man/readlink.x
index 79ba758..6b28bca 100644
--- a/man/readlink.x
+++ b/man/readlink.x
@@ -1,6 +1,6 @@
 [NAME]
-readlink \- print value of a symbolic link or canonical file name
+readlink \- print resolved symbolic links or canonical file names
 [DESCRIPTION]
 .\" Add any additional description here
 [SEE ALSO]
-readlink(2)
+readlink(2), realpath(1), realpath(3)

> And finally: -n is pretty much useless now with multiple arguments,
> because the output is just concatenated together:
>
>    $ src/readlink --no /user /user
>    homehome

> Wouldn't it be better to allow -n only for single-argument calls,
> or use a blank " " as delimiter between the output for multiple
> args, or warn?

Since -n is a largely redundant option anyway,
I was just keeping it around for compat reasons.
BSD operates like above, so why diverge?

thanks for the detailed review,
Pádraig.