[Top][All Lists]

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

[Octave-bug-tracker] [bug #62847] addpath fails to process network pathn

From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #62847] addpath fails to process network pathnames
Date: Mon, 1 Aug 2022 15:24:36 -0400 (EDT)

Follow-up Comment #2, bug #62847 (project octave):

Thanks Markus for responding quickly :-)

A correction: I see the behavior also with 7.2.0, but not with 7.1.0.
(I think I erred there because the NSIS installer, when installing several
Octave versions side by side, usually picks up the previous Octave
installation and puts its path into the new desktop shortcuts. I forgot to fix

Not an error but a warning (typed over from the remote desktop, I can't
copy/paste over VMWare and Savannah is blocked by the company's firewall),
along the lines of:

warning: addpath: Q:\full\path\to\some\network\subdir: no such file or
warning: called from
     < some local helper .m-file that adds paths > at line x column y
     E:\.octaverc at line z column t

(where E:\ is a local drive) and from which we can conclude that
0 an error (not being able to add a requested path) is disguised as a warning.
Looks inconsistent to me and something users wouldn't perceive as worth merely
a warning
0 ? addpath seems prepared to add files to the path? (OK that's mere

Admittedly, at the company I work for the network mapping vagaries and
intricacies are a bit untractable for mere mortals like me.
E.g., where I wrote that drive letter "Q:\" may resolve to
'\\SP500.company.local', after adding the path cf. my example 3 the pertinent
path entry looks like '\\BC312.company.local\rest\of\path'. So the base server
name has been silently substituted as well. Furthermore in the network disk's
properties under the DFS [*] tab, the start of the path just looks like
A sysadmin once assured me this is all run-of-the-mill Windows network mapping
management and processing. So I conclude this should all be transparent to
programs like Octave. And it apparently is, up till 7.1.0.

BTW I've noted this behavior since maybe a few weeks.

I do have a kludge workaround: in the helper .m file I mentioned I've added a
strrep to replace the drive letter with the pertinent '\\server.company.local'
UNC start, but as that can chance unpredictably (for me) it's not a robust
Furthermore, it's a bit untenable to include strrep into any addpath call at
the command prompt (e.g., by aliasing addpath) as we have several drive
letters each pointing to possibly separate servers.

[*] DFS stands for 'Distributed File System'


Reply to this item at:


Message sent via Savannah

reply via email to

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