On Fri, Jul 22, 2022 at 05:04:09PM +0100, Jonathan Wakely wrote: > On Fri, 22 Jul 2022 at 15:53, Robert Elz via austin-group-l at The > Open Group <austin-group-l@opengroup.org> wrote: > > Aside from that possibility the only reason would seem to be the same > > as why echo (real ones) have -n (and trashy ones have \c) and why > > printf(1) needs a \n to print one ... there are times that it is useful > > to write a partial line to stdout (or wherever) and there's no reason > > that the output of readlink could not be intended to be a part of such > > a gradually constructed output line. > > But then shouldn't *every* command that prints output have a -n option? > > If you need to include the output of readlink in gradually constructed > output you can do what you have to do with other commands: > > printf '%s' "$(readlink foo)"
That strips trailing newlines that may have been important. The link contents $'abc' and $'abc\n' are indecipherable under your approach of a path through $() and printf. If you are going to output a constructed filename to stdout, you really DO want: readlink -n foo && echo /newfile to produce the output "link/content/newfile" when foo contains 'link/content', and still handle the case where foo's content is instead something with a trailing newline. > > The fact that echo and printf have that feature means you don't need > it everywhere. You don't need it for utilities that are seldom used in generating partial file names; but for programs like dirname and readlink, providing a simpler way to use the utility in the context of building up a larger file name without losing intermediate trailing newlines that would be eaten by $() is enough of a worry that adding things like -n to make it more useful was worthwhile to the implementors. I'm aware that 'dirname -n' is not common implementation practice, but since 'readlink -n' does appear to be, there's no harm in standardizing it that way. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
