Re: PATCH: relpath

[Eric Blake]

On 12/02/2011 02:45 AM, Jim Meyering wrote:
> Just because others use a name doesn't make it good.
> 
> IMHO, "relpath" is not a very good name.
> One minor issue is with the word "path" in "relpath".
> "PATH" is often used to mean a shell's search "path" (list of directories).
> "file name" is the meaning we want, but many people think "file name" cannot
> mean "directory name".  But they can be educated ;-)

'realpath' mirrors the POSIX function in libc by the same name; we're
stuck with it, not to mention that realpath(1) exists in BSD.

But I tend to agree with you that 'relname' sounds nicer than 'relpath',
especially given GNU Coding Standards recommendation to avoid 'path'
except when talking about colon-separated lists of directories, and in
spite of POSIX confusingly treating 'path' as a synonym to 'file name'.

> 
> If we wanted to go for readability, directory-relative-file-name
> might work.  But that's obviously too long.
> 
> So if we consider new names, here are possibilities:
> 
>   relname

I like this best.

>   rel-name
>   dir-rel-name

These are longer to type, and fly in the convention that none of the
other coreutils have '-' in the name.

Tab-completion-wise, I'd probably be thinking along these lines:

I want a shell utility like realpath(3) that gives me an absolute name -
I'll try 'real<TAB>' - ah, there's realpath.

I want a shell utility that will give me a conversion of one name into a
relative location from another - I'll try 'rel<TAB>' - ah, there's relname.

I don't have any hits on my current F16 system for either 'real<TAB>' or
'rel<TAB>' (but get several tools starting with 'read<TAB>'), so I think
we have unique enough of a prefix that people would be able to find the
tool(s) regardless of the suffix being 'path' or 'name'.

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

signature.asc
Description: OpenPGP digital signature