path normalisation in "base"

Daniel J. Luke dluke at
Tue Oct 11 06:21:09 PDT 2016

one way to handle it could be:

% svn diff
Index: port.tcl
--- port.tcl	(revision 153771)
+++ port.tcl	(working copy)
@@ -2389,7 +2389,12 @@
         return 1
     foreach filename $portlist {
-        set file [file normalize $filename]
+        # don't normalize absolute paths
+        if {"/" ne [string index $filename 0]} {
+            set file [file normalize $filename]
+        } else {
+            set file $filename
+        }
         if {[file exists $file] || ![catch {file type $file}]} {
             if {![file isdirectory $file] || [file type $file] eq "link"} {
                 set port [registry::file_registered $file]

Before -
% port provides `which nmap`
/Volumes/Data/opt/local/bin/nmap is not provided by a MacPorts port.
After -
% port provides `which nmap`
/opt/local/bin/nmap is provided by: nmap

> On Oct 11, 2016, at 9:07 AM, Daniel J. Luke <dluke at> wrote:
> see also:
> which I linked to the last time you brought this up.
> (no one replied to that original post).
> I expect no regular base contributor cares enough about that unsupported configuration to work on it - which means someone who does care (you, perhaps?) needs to generate and test a change that can be incorporated (otherwise we'll just keep having this conversation every year or so).
> On Oct 11, 2016, at 4:43 AM, René J.V. Bertin <rjvbertin at> wrote:
>> I'd like to understand a bit better why the base layer does path normalisation in a number of places where its use isn't immediately obvious to me, like for instance the action_provides procedure in the port script. If that's not so broad of a question that it cannot be answered with a single, succinct explanation.
>> I can see how it would probably be required in a sandboxing context, and I have no idea exactly what kind of sandboxing MacPorts does. (I do seem to recall whatever issues it had with e.g. a symlinked $prefix were resolved a while ago.)
>> To come back to action_provides: if the registry saves a port's "intended" paths (the ones stored in the software image tarball), why do a lookup of the actual/resolved path? That would make it impossible to check which port installs a symlink (to a file or directory installed by itself, some other port, or even to something in system space), regardless of whether there are "unexpected" symlinks in the path, no?

Daniel J. Luke

More information about the macports-dev mailing list