On 2020/09/20 23:41, Stefan Sperling wrote: > On Sun, Sep 20, 2020 at 11:06:21PM +0900, Yasuhito FUTATSUKI wrote: >> On 2020/09/19 5:26, Yasuhito FUTATSUKI wrote: >>> Hi, >>> >>> While I tried to make an example that escape_path() does not work as >>> expected in specific locale such as ja_JP.SJIS or CP932 (suggested by >>> Jun), I found it seems svn_cmdline__edit_file_externally() always >>> passes the file name as UTF-8 even if the LC_CTYPE is other than >>> UTF-8. >>> >>> I think it is also need svn_path_cstring_from_utf8() conversion for >>> file_name in svn_cmdline__edit_file_externally(). >> >> As far as I read the code, svn_cmdline__edit_file_externally() is >> called with paths come from svn_io_open_unique_file3() or >> "local_abspath" from svn_client_conflict_t, so I believe it is >> needed. > > Your patch looks good. I have one question below: > >> I wrote a patch address it. >> (attached fix-edit-file-externally-patch.txt) >> [[[ >> Fix file name to edit from utf8 to local style. >> >> * subversion/libsvn_subr/cmdline.c (svn_cmdline__edit_file_externally): >> Apply svn_path_cstring_from_utf8() to target file name. >> ]]] >> >>> Here is a reproucing script. (Using ja_JP.UTF8 and ja_JP.SJIS locale). >> >> As it is quite few system can use ja_JP.SJIS locale (I only know >> FreeBSD and macOS) and there is also escape_path issue in SJIS locale, >> I modified this script to use ja_JP.eucJP locale. > > It looks like apr_escape_shell() will escape 0x5c (backslash, \) when > looking for ASCII character bytes. When 0x5c is escaped this breaks the > SJIS-encoded byte sequence.
Yes, it is right. > Have you already tried always using escape_path() on the UTF-8 version of > the string, and then converting the escaped path to the locale's encoding? > In other words: First use escape_path, then use svn_path_cstring_from_utf8? > Perhaps that will make SJIS work? Ah, I didn't make sense. I'll try and then post a new patch. Thank you very much! Cheers, -- Yasuhito FUTATSUKI <futat...@yf.bsclub.org>
