Re: PATCH: relpath

[Dmitry V. Levin]

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

pgpa0Q7theZSH.pgp
Description: PGP signature