coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: relpath


From: Eric Blake
Subject: Re: PATCH: relpath
Date: Thu, 01 Dec 2011 15:18:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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.  But it fits closely to the
readlink(2) function that it wraps, and canonicalization is just a
matter of repeated readlink calls, so it isn't that much of a stretch.
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).

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', sharing a code base with slightly different
defaults depending on which application you invoke (GNU Coding Standards
prevent us from doing it directly by argv[0], which is why 'ls' and
'dir' are separately linked, rather than 'dir' being a symlink to 'ls').

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.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]