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

[Pádraig Brady]

On 12/12/2012 08:19 PM, Jim Meyering wrote:
> Pádraig Brady wrote:
> > On 12/12/2012 07:05 PM, Aaron Davies wrote:
> > > Is there a reason the interface for readlink(1) is “FILE” instead of
> > > “FILE...”? I’ve often wanted to do e.g. “find -type l|xargs
> > > readlink” or (in zsh) “readlink **/*(@)”, and having to do a shell
> > > loop or use “xargs -n1” seems inelegant.
> >
> > Note the newer more general realpath(1)
> > supports multiple files.
> >
> > Though there is no reason I see that readlink(1)
> > can't do so too.  I also see the BSD version
> > can accept multiple args, so I'll probably add
> > something along the lines of the following
> > unless there are objections.
>
> Thanks.  That seems like the right way to go.
>
> ...
> > +      const char *fname;
> > +      char *value;
> > +      fname = argv[optind];
> ...
> > +      value = (can_mode != -1
> > +               ? canonicalize_filename_mode (fname, can_mode)
> > +               : areadlink_with_size (fname, 63));
>
> Maybe save two lines in the loop body by moving each of those declarations
> down to its initialization?
>
>           const char *fname = argv[optind];
>           char *value = (can_mode != -1
>                          ? canonicalize_filename_mode (fname, can_mode)
>                          : areadlink_with_size (fname, 63));

Yes. that's better.
I also notice we can change from printf() to fputs() to gain some speed.
So the output portion is now:

+          fputs (value, stdout);
+          if (! no_newline)
+            putchar (use_nuls ? '\0' : '\n');

The awkward/somewhat redundant -n, --no-newline option
is handled in the same way as on BSD and the help text adjusted like:

-  -n, --no-newline              do not output the trailing newline\n\
+  -n, --no-newline              do not output the separator character\n\

thanks,
Pádraig.