[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: add relative_file_name procedure to encapsulate logic for "su

From: Jacob Bachmeyer
Subject: Re: PATCH: add relative_file_name procedure to encapsulate logic for "subdir" variable
Date: Mon, 03 Dec 2018 23:29:47 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]