Ben Elliston wrote:
On Mon, Dec 03, 2018 at 09:56:30PM -0600, Jacob Bachmeyer wrote:
This is part of my ongoing efforts to improve DejaGnu's integration
with Automake. I think that "relative_file_name" could be a useful
utility procedure and will be able to fill any remaining gaps when
subdir is eventually deprecated. This also replaces two slightly
different ways of deriving what should be the same value.
What you have written is very similar to the UNIX realpath(1) utility
with the --relative-to option. Can you perhaps rename your proc to
realpath_relative?
I had not considered this earlier.
The choice of "file name" was originally motivated by the note in the
GNU Coding Standards ("We use the term 'path' only for search paths,
which are lists of directory names.") about avoiding the term
"pathname". However, that is in the section on manuals, so I suppose
that I could do either in the code. Also note that relative_file_name
only manipulates file names; it does not interact with the actual file
system in any way. (The proc is expected to be called with absolute
file names, so "file normalize" is only used to produce a result instead
of raising an error in accordance with "be liberal in what you
accept".) It will, as written, produce incorrect results on systems
that have multiple volumes if asked to produce a relative file name
between volumes. Tcl does not seem to have a good way to handle this
portably, and it cannot happen on the GNU system, which uses the Unix
port of Tcl. :-)
In particular, if I understand the documentation correctly, realpath(1)
also resolves symlinks and processes "/./", "..", and multiple slashes.
The relative_file_name procedure does some of that, but only
incidentally due to the use of "file split" and "file join".
In other words, it probably should remain as "relative_file_name", since
"realpath_relative" implies a different (and more extensive operation)
as I see it. At the least, "realpath_relative" would apply "file
normalize" to both arguments unconditionally, even though this could
produce surprising results in some situations involving edge cases with
symlinks. Those edge cases would also be hard to debug, since users bit
by them may not realize that symlinks are involved in the problem. As a
pure utility procedure, "realpath" and variants could be useful, but
could be dangerous to call from the core due to this sensitivity to the
filesystem that this patch lacks.
-- Jacob
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
