path normalisation in "base"

Rainer Müller raimue at
Tue Oct 11 09:45:10 PDT 2016

On 2016-10-11 16:38, René J.V. Bertin wrote:
> This does work though:
> {{{
> proc macports::normalize { filename } {
>     # normalise the user-specified prefix. The test file under $prefix need not exist for that:
>     set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
>     set file [file normalize $filename]
>     # check if the result starts with the "normalised" prefix:
>     if {$nprefix ne $macports::prefix && [string first $nprefix $file] eq 0} {
>         # obtain the part after the normalised prefix, and prepend the user-specific prefix to it:
>         set file [file join $macports::prefix [string range $file [string length $nprefix]+1 end]]
>     }
>     return $file
> }
> }}}

This might solve the ${prefix} being a symlink. Do we want to treat that
as a supported special case after all?

If ${prefix}/bin is a symlink, this would still not work as expected.
How do we decide when to honor a symlink put in place by a port versus
ignoring a manual replacement in normalization? At which paths do we
want to support symlinks?

We make certain assumptions about ${prefix}, such as the common check
for [file writable ${prefix}] throughout the code. We should make sure
these always follow the symlink and not report status of the symlink
itself. Symlinks have their own permission bits on HFS+, can be changed
by chmod -h and will adopt umask on creation.


More information about the macports-dev mailing list