Peng Yu wrote: > Hi Jim, > >> realpath --relative-start=DIR FILE ... > > I had some private email conversation with Eric. Per Eric's > suggestion, it is better to document it to the mailing list for future > reference and to make my point clearer.
Keeping discussion on the mailing list is almost always preferred. > Just that there is a 3rd party command realpath (which doesn't have > the relative path capability), it doesn't mean that the name realpath > should be followed. When we name a command to compute relative path, Don't worry. We do not feel obliged to do anything. Our goal is to find the "right" solution to a hard optimization problem: to use a name that makes sense, yet that sometimes must be balanced by prior use and compatibility with programs on other systems. > we need to forget about that there is a command call realpath > somewhere, so that It becomes pretty clearly that relpath is a > straightforward and easy-to-understand name. ... > perl: canonpath > python: os.path.realpath > ruby: expand_path > > Each of them is a better name than readlink. > > If "canonicalization" were not named correctly, why don't we take the > chance to name the relative path tool correctly this time? 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 ;-) 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 rel-name dir-rel-name
