[Octave-bug-tracker] [bug #57083] pkg list does not indicate loaded global packages

[Philip Nienhuis]

Follow-up Comment #4, bug #57083 (project octave):

Your hunch is a good one.

For e.g., geometry I get in the stanza you mention:

tmppath =
....;C:/Programs/Octave/Octave-6.0.0_20191017L/mingw64/share/octave/packages/geometry-4.0.0;...


while the string it is compared with looks like:

debug> strrep (installed_pkgs_lst{i}.dir, '\', '/')
ans =
C:/Programs/Octave/OCTAVE~4.0_2/mingw64/share/octave/packages/geometry-4.0.0


but:

debug> strrep (canonicalize_file_name (installed_pkgs_lst{i}.dir), '\', '/')
ans =
C:/Programs/Octave/Octave-6.0.0_20191017L/mingw64/share/octave/packages/geometry-4.0.0


gets me the right string.

Looking at it from a little distance I get the impression that the strrep()
statements to morph the Windows fileseps to forward slashes serves no purpose
anymore here. But the short pathnames (exclusively for Windows, the ones with
"...\OCTAVE~4.0_2\..." rather than "...\Octave-6.0.0_20191017L\...") occur
elsewhere in the path() as well and appear to clobber up.

Perhaps the way to go here is to use canonicalize_file_name() to reconstruct
the (on Windows) native long file names (LFN) everywhere in the
private/installed_packages.m function, keep the fileseps as-is and only then
compare.
IOW something along the lines of

strfind (path, canonicalize_file_name (installed_pkgs_lst{i}.dir))


(Of course I already see a few gotchas but those can be tackled.)
AFAIU "pkg list" isn't a time-critical function so a little more processing
time, if any, won't hurt.

IMO another benefit is that "pkg list" would then return installed package
pathnames that are much more understandable to users then the short path names
that are returned currently (compare the second verbatim block with the first
or third).

What do you think?
If you agree I'll try to come up with a cset along these lines

    _______________________________________________________

Reply to this item at:

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

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