[DTrace-devel] [PATCH] Add support for cleanpath() subroutine

[Alan Maguire]

On 21/11/2023 04:56, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh at oracle.com>
> 
> Replace all "//" with "/".
> Replace all "/./" with "/".
> Replace all "../foo/" with "/".
> 

A few questions about this below...

> Notice that the results differ in some cases from what was
> done in legacy DTrace:
> 
>     input string         current patch     legacy DTrace
> 
>     ""                   "."               ""
> 

I wonder about this substitution. If an empty path in a kernel data
structure connotes "no file is associated with this object", replacing
it with "." seems like it could be misleading.

>     "/foo/bar/baz/"      "/foo/bar/baz"    "/foo/bar/baz/"

Question about this one below...

>     "/."                 "/"               "/."
>     "a/."                "a"               "a/."
>     "./a"                "a"               "./a"
> 
>     "../.."              "../.."           "."
>     "a/.."               "."               "a"
>     "a/../.."            ".."              "a"
> 
>     "a/../b"             "b"               "/b"
>

...and presumably "/a/../b" becomes "/b", right?	

> In the first case, one can argue about which implementation is
> "correct."
> 
> In the next cases, there are unnecessary trailing '/' or '.' or
> both or unnecessary leading "./".  They would seem to be wrong.
> 
> In the next cases, the legacy results are clearly wrong, not
> handling ".." correctly.
> 
> In the final case, a relative path is converted into an absolute
> path, which is also clearly incorrect.
> 

This all seems fairly consistent with the description at

https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/dtrace-guide/cleanpath-subroutine.html

...aside from (perhaps)

     "/foo/bar/baz/"      "/foo/bar/baz"    "/foo/bar/baz/"

I think the question is if the trailing "/" is a valid redundant
element to eliminate, right? Whether it is redundant probably
hinges on how the cleanpath()ed path will be used; it could be argued
that it's potentially useful information that it is a directory rather
than a file. If for example we were using cleanpath()ed paths as an
aggregation key, seeing which were files versus directories could
potentially be useful data. Looking around at scripts that use
cleanpath(), most use it to output the cleaned-up path, so maybe it's
not a huge deal, but it does seem to stretch the concept of redundancy
somewhat beyond the original intent. That's just my interpretation
though, I don't feel too strongly about it.

Thanks!

Alan