[Top][All Lists]

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

[Octave-bug-tracker] [bug #62865] 'path' should return drive letter, not

From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #62865] 'path' should return drive letter, not UNC path when 'addpath' was called with drive letter
Date: Sat, 6 Aug 2022 03:22:58 -0400 (EDT)

Update of bug #62865 (project octave):

                Priority:              5 - Normal => 3 - Low                


Follow-up Comment #1:

> Since (IIRC) 7.x.x, network paths returned by the 'path' command are shown
as UNC paths, regardless of what kind of path was fed to the 'addpath'

To clarify: That is not correct in general. `canonicalize_file_name` still
returns paths starting with the mapped network drive letter unless that path
contains a symbolic link that points to a UNC network share that *differs*
from the network share corresponding to the mapped network drive letter. Fwiw,
it would also return that UNC path if the symbolic link pointing to a UNC
network share would reside on a local disc.

Imho, that behavior of `canonicalize_file_name` is correct and matches how it
is documented for POSIX.

If servers are swapped and mapped drive letters or symbolic links would be
changed to point to different servers, `canonicalize_file_name` would
automatically resolve to those new servers. So, I don't think the second point
you raise is something we'd need to worry about.

Which sort of path (drive root or UNC) is easier to understand probably
depends on which a user is more exposed to. E.g., where I'm working, UNC paths
are used pretty commonly...

Imho in this particular case, we don't need to be 100% Matlab compatible. It's
not like an evaluation result would differ because of this difference in

However, I tend to agree that it might be less surprising if addpath wouldn't
change paths that it was fed. However, there is probably a reason why the
paths are canonicalized currently. Changing anything revolving around the load
path implementation tended to be critical in the past. So, if there is just a
"cosmetic" reason for changing this, the "costs" of changing this need to be
Additionally, this only affects very specific use cases (symbolic links that
point to different network shares).

Lowering the priority because of this.


Reply to this item at:


Message sent via Savannah

reply via email to

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