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

[Philip Nienhuis]

Follow-up Comment #10, bug #62865 (project octave):

I can very reliably reproduce the issue in comment #6.

Does your CMD.exe support UNC paths? seems to be some (registry?) setting
somewhere.
At my work that setting is completely shielded from us. AFAIK we have quite a
bit of legacy SW like SCADA systems and PLC stuff, maybe that is a reason.

I have a Windows build from Aug. 7,
7f4ad92265d2
maint: Merge stable to default.
author  Markus Mützel <markus.muetzel@gmx.de>


As to JWE's remark in comment #:
I can follow his (and apparently your) reasoning, esp. the part about just one
unique name for a path entry. But he didn't motivate *why* that should be the
actual name of the directory rather than symlinks. Yet instinctively I even
agree on that.
However, the thing is that on Windows, drive letter paths seem to have some
extra associated "magic" compared to just symlinks. That "magic" might be
little more than translating UNC paths into drive letter paths for
applications not being able to use UNC, possibly through legacy file system
calls. Yet the consequences pop up all the time, usually harmless, but
sometimes adversely.

My point still stands that if users enter & use drive letter paths, they'll
expect, and IMO are entitled to expect, to see drive letter paths returned to
them.
If Octave morhps them into UNC paths behind the scenes and only uses those,
well that's fine and I would fully support that.



    _______________________________________________________

Reply to this item at:

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

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