Mon 27 Mar 2017 08:42:58 PM UTC, comment #22:
The GUI retains the settings.
|
Mon 27 Mar 2017 05:19:49 PM UTC, comment #21:
@Márton: To clarify the severity of this bug: Is it possible for you to start the GUI at all? If it does start, does the GUI retain settings between sessions (e.g. can you change the GUI language)?
|
Sat 25 Mar 2017 09:35:06 AM UTC, comment #20:
Please, when fixing this patch, don't forget to test the case where the Windows username contains an accent. I ended up with this username when I created my Windows account based on my Microsoft account and my real name, which is Márton. My user data directory is consequently C:\Users\Márton, and when I start Octave, either CLI or GUI, it says
and I cannot access files and folders inside my user directory at all.
|
Sun 13 Nov 2016 01:50:56 PM UTC, comment #19:
I just uploaded a patch (file #38945) to bug #49118 which might partially solve the issue here, too.
|
Tue 29 Mar 2016 06:51:10 AM UTC, comment #18:
Workaroud to access the files in the directories with non-ASCII characters. (for files I do not find the work around)
From cmd prompt
C:\Users\Tatsu>subst /?
Associates a path with a drive letter.
Explanation of the subst command
For the "path" you can use UNC path so that you can access Network drive which does not have a drive letter.
Of course, make xxx.bat file is useful.
|
Sat 16 May 2015 12:37:02 AM UTC, comment #17:
Torsten
Thank you for your reply.
I have tried to build octave with the same patch as yours.
For my case, result was same as for octave-4.0.0-rc2
https://savannah.gnu.org/bugs/?44538
Tatsuro
|
Thu 14 May 2015 07:43:29 AM UTC, comment #16:
I have added the options into the main Makefile, here the diff:
|
Mon 11 May 2015 09:30:53 AM UTC, comment #15:
Torsten
How did you do that?
(I have build mxe-octave adding -DUNICODE and -D_UNICODE to the compile flags in the Makefile and changed the codepage to 65001 in the terminal window.)
I have tried to add -DUNICODE and -D_UNICODE in CFLAGS and CXXFLAGS in src/octave-mk and built mxe-octave (4.0.0-rc4) However, my results were different.
The ls command at codepage 932 (Japanese), ls command gives broken screen but they are different from octave-4.0.0-rc4 on ftp alpha site.
After system('chcp 65001'), for me, ls command works perfect.
The system('type nihongo.m') represent Japanese characters but nihongo.m did not work.
I could not handle path and file names which contain Japanese multibyte character are not able to be handled.
MinGW page suggests to use wmain or _tmain and use wchar or tchar.
However the use of it loses portability of the code.
I cannot figure out what is the good solution for this matter.
|
Sun 10 May 2015 08:23:53 AM UTC, comment #14:
I guess it is related since the mxe build seems to be an ansi, not an unicode build.
I have build mxe-octave adding -DUNICODE and -D_UNICODE to the compile flags in the Makefile and changed the codepage to 65001 in the terminal window. The result was that 'dir' shows the correct names (with German umlauts) whereas 'ls' does not. Double clicking a folder with umlauts in the file browser correctly changes the directory which can be checked by 'pwd' showing the correct name.
With codepage 850, 'ls' works correctly but 'dir' does not. A double click on a folder with umlauts still correctly changes the directory.
|
Sat 09 May 2015 08:17:25 PM UTC, comment #13:
http://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/
Is the above related?
|
Sat 09 May 2015 11:05:00 AM UTC, comment #12:
gnulib::readdir and opendir (for mingw) is a wrapper around Windows FindNextFile etc
|
Sat 09 May 2015 03:59:51 AM UTC, comment #11:
octave uses gnulib dirent related functions.
However, mkdir, readdir, opendir seem not be used.
Can the situation be changed if gnulib alternatives are used ?
|
Fri 08 May 2015 08:58:21 AM UTC, comment #10:
I have test the mxe-octave that used gcc-5.1.0.
I cannot handle file names and path names which contain non-ascii character gcc-5.1.0 based mxe-octave.
The gcc-5.1.0 seems not to be solution for this issue.
|
Sun 22 Mar 2015 02:15:32 PM UTC, comment #9:
Interestingly, writing some code in Visual C++ 2008, using the WIn32 functions for directory traversal, and _tstat for the stat function, the Win32 code works in compiled as Unicode.
The code fails for the stat function is set to multibyte mode. The filenames at that point (multibyte mode) are the same as what mingw is getting from readdir.
|
Sun 08 Mar 2015 06:46:46 PM UTC, comment #8:
I cannot speak for the original poster, but I guess bug #43099 is pretty similar.
|
Sun 08 Mar 2015 05:19:07 PM UTC, comment #7:
Maybe - I dont know if it is only that the system functions are getting/providing incorrect values, which then will be displayed incorrectly, or whether there are also display of the utf-8 string issues as well.
|
Sun 08 Mar 2015 02:44:39 PM UTC, comment #6:
Is there any difference between this bug and bug #43099?
|
Thu 05 Mar 2015 05:57:07 PM UTC, comment #5:
Writing a standalone c program that uses open/read/close dir and stat functions in mingw, it appears that when providing the d_name from readdir to the mingw stat function, it fails (only for the utf8 named files)
|
Wed 04 Mar 2015 06:50:38 PM UTC, comment #4:
Single step through a = dir() shows:
|
Wed 04 Mar 2015 05:46:31 PM UTC, comment #3:
On my machine, I have a folder and file that are using Unicode characters.
For both gui and cli (windows)....
Runing in octave, 'ls' and they show names (although names are mangled for the Unicode files).
Running in octave 'dir', and they do not seem to be shown at all.
If I run:
I see for those files:
|
Fri 04 Apr 2014 07:06:59 AM UTC, comment #2:
You are right, there is the same issue with the Command Line only version of Octave.
But it is more visible in the GUI, because the GUI elements have been nicely translated with Umlaut :-)
4) Right, I just noticed that the Grave and Circumflex are ASCII, the Degree and Acute are not.
6) Probably not only the file system, but the whole library functions.
|
Fri 04 Apr 2014 03:41:09 AM UTC, comment #1:
This works fine for me on a Linux system with 3.8.1, so likely specific to Windows filesystems or the library functions Octave is using to work with Windows files and directories.
Since you verified that the same commands in the command window do not work, this is not really a GUI issue at all.
|
Thu 03 Apr 2014 09:32:09 AM UTC, original submission:
There are some special issues when using "Umlaut" characters on a German keyboard. Running Octave 3.8.1 under Windows 7 x64 German edition
https://de.wikipedia.org/wiki/Umlaut
Let's say we are actually in the folder "D:\Octave" and there is a subfolder "D:\Octave\München"
1) In the file browser, "München" will be displayed correctly.
2) Some translated texts contain Umlaut characters. OK.
3) When double-clicking on the name "München", the message "error: D:/Octave/M**nchen: No such file or directory" will appear.
(** = garbled text, looks like Unicode)
According to the file browser, the directory has been successfully changed.
According to the "Current Directory" line, the current directory is still "D:\Octave"
Same with "pwd" answer.
4) When trying to enter "cd 'München'" in the command window by hand, the Umlaut "ü" will be replaced by a verical bar '|'.
Actually, a limited num
ä => d
Ä => D
ö => v
Ö => V
ü => |
Ü => \
° => 0 (degree symbol)
´ => 4 (acute accent)
5) Getting the Umlaut via copy & paste from an external ANSI editor is not pssible, either.
6) Messages in the command history get garbled. For example, the time stamp "Mitteleuropäische Zeit" after starting octave GUI is reading "Mitteleurop?ische Zeit".
|