Re: PATCH: add relative_file_name procedure to encapsulate logic for "subdir" variable

[Jacob Bachmeyer]

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