Re: PATCH: relpath

[Peng Yu]

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.

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,
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.

Bottom line, I don't think that it is necessary to make the interface
less obvious by considering some 3 party packages. If 3rd party
packages should be considered, why don't we consider these examples.

The corresponding relative path functions from the following languages are

perl: abs2rel
python: os.path.relpath
ruby: relative_path_from

These three languages all have separate functions for realpath.

python: os.path.realpath(path)
perl: realpath
ruby: realpath

If it were a good idea to merge both functions into a single name
realpath, why this is not done in these languages?


> 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.
Again, the corresponding function in the following three languages are

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?

-- 
Regards,
Peng