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.
