On Fri, Dec 02, 2011 at 03:25:45AM +0400, Dmitry V. Levin wrote: > On Thu, Dec 01, 2011 at 03:18:09PM -0700, Eric Blake wrote: > > On 12/01/2011 03:00 PM, Peng Yu wrote: > > > > > >> but few people know that hidden within readlink they will find a > > >> file-name canonicalization tool > > > > > The reason is "readlink" is not a good name for canonicalization. > > > > That's true; we've had a number of people wonder why coreutils doesn't > > have 'realpath' only to learn that 'readlink' can do what they are used > > to 'realpath' doing on other implementations. > > > > We can't ditch the name 'readlink' now. > > Neither we could in August of 2002 when it was discussed for the first > time. There were several different 'readlink' utilities at that time, > including one from tetex and OpenBSD-derived one distributed by Debian. > As result, since our coreutils 'readlink' had to be compatible with all > these alternative 'readlink' utilities, it has its name and its not quite > so obvious usage interface. > > > But adding the name 'realpath' would let us match other implementations > > that already have realpath(1), whereas I don't know of any > > implementations with a relpath(1). > > There is a 'relpath' utility in freebsd ports, see > http://lists.gnu.org/archive/html/coreutils/2011-11/msg00051.html > > > Historically, we've had problems with similarly-named apps. Right now, > > we have 'ls', 'dir', and 'vdir' that share a code base. At one point, > > we tried to have 'groups' be a shell wrapper around 'id', but it had so > > many bugs that when we finally bit the bullet and made them both C > > programs with a shared code base, maintenance was eased. We also > > provide '[' and 'test' (POSIX requires both names, and they differ on > > whether they can support '--help' and/or require ']'). Conversely, we > > don't provide a 'hexdump', even though it would be trivial to do by > > sharing a code base with 'od'. > > > > Maybe this really is a case where we want all three names, 'readlink', > > 'realpath', and 'relpath', > > From one side, adding both 'realpath' and 'relpath' might be a bit confusing. > From another side, adding 'relpath' to a system which already has > 'realpath' is not less confusing. And disguising "relative path" > functionality under 'realpath' umbrella is even more confusing. Unlike > 'readlink' case, no existing 'realpath' implements "relative path" mode yet, > so there is no strict necessity to introduce 'realpath' with 'relpath' > capability. > > > I'm hoping that we get enough comments in this thread to make a naming > > decision that we can justify as making more sense than any of the other > > alternatives that were presented at the same time. > > We have three alternatives so far: > - add 'relpath' (probably compatible with 'relpath' from freebsd ports); > - add 'realpath' (compatible with existing 'realpath' implementations) > AND with --relative-start option; > - add both 'relpath' and 'realpath'. > > Which one makes more sense? > > > -- > ldv
and what about something like: getpath -C|--canon // simulate realpath getpath -R|--relative // simulate relpath getpath -L|--link // simulate readlink ? just a thought. -- Regards, Guillaume
