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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
