Re: PATCH: relpath

[Jim Meyering]

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