[Octave-bug-tracker] [bug #49118] GUI editor cannot run file in folder name with umlaut

[Markus Mützel]

Follow-up Comment #35, bug #49118 (project octave):

There is still a lot more to do. Even if it is now possible to change to a
directory with Umlauts, there are still problems executing files in there.
Executing the un-modified file works. However, when I modify and save it in
the editor, I get:

HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
  #000: /yyy/mxe-octave/tmp-hdf5/hdf5-1.8.14/src/H5F.c line 439 in
H5Fis_hdf5(): unable open file
    major: File accessibilty
    minor: Not an HDF5 file
  #001: /yyy/mxe-octave/tmp-hdf5/hdf5-1.8.14/src/H5Fint.c line 554 in
H5F_is_hdf5(): unable to open file
    major: Low-level I/O
    minor: Unable to initialize object
  #002: /yyy/mxe-octave/tmp-hdf5/hdf5-1.8.14/src/H5FD.c line 992 in
H5FD_open(): open failed
    major: Virtual File Layer
    minor: Unable to initialize object
  #003: /yyy/mxe-octave/tmp-hdf5/hdf5-1.8.14/src/H5FDsec2.c line 343 in
H5FD_sec2_open(): unable to open file: name =
'D:/SVN/Octave/��ml����t/testing_utf8_2.m', errno = 2, error
message = 'No such file or directory', flags = 0, o_flags = 0
    major: File accessibilty
    minor: Unable to open file


Where yyy is the path to the mxe-repo in Linux. The folder I was testing with
was "D:/SVN/Octave/Ümläüt".

The change in the file is ignored (the old file is executed).
After I do a "path(path)" which normally helps when Octave does not pick up
changed files, I get a dialog with: 
"The file D:/SVN/Octave/Ümläüt/testing_utf8_2.m is shadowed by a file with
the same name in the load path. To run or debug the function you are editing,
change to the directory D:/SVN/Octave/Ümläüt."
When I click on "Change Directory", the same dialog pops up again.
Oddly, this happened after I ran the test file from the command window.

Additionally, the path is not displayed correctly in the "Current Directory:"
dropdown list.

I guess the results from "dir" have to be converted from UTF-16 to UTF-8 as
well?

Seeing all this, I'd like to propose that we don't block 4.2 on this issue
(even if it is marked as a regression). Working with non-ASCII characters on
Windows never really worked in Octave. Some aspects improved, some aspects got
worse since the last release. But I think we are on the right track with
accepting patches which move us towards "UTF-8 everywhere" even on Win32.

Having said that, I would like to continue working on that bug if someone
could give me some help.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49118>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/