Re: PATCH: relpath

[Guillaume Kielwasser]

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