[Octave-bug-tracker] [bug #62865] 'path' should return drive letter, not UNC path when 'addpath' was called with drive letter

[Markus Mützel]

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'
command.

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
behavior.

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
considered.
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:

  <https://savannah.gnu.org/bugs/?62865>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/