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
