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

[Jim Meyering]

Pádraig Brady wrote:
> 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');

Thanks.  Another improvement.

> 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\

Good point.
Now that the long-named --no-newline is a misnomer, we might want to
provide a better long-named option (like --no-separator) and begin the
deprecation process.  E.g., warn that the --no-newline option is being
deprecated, and add a FIXME to give an error in a few years.