[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28180: [w32] Unicode characters in subprocess (git) arguments change
From: |
npostavs |
Subject: |
bug#28180: [w32] Unicode characters in subprocess (git) arguments changed to space |
Date: |
Mon, 21 Aug 2017 22:35:24 -0400 |
In w32.c there is a comment saying
. Running subprocesses in non-ASCII directories and with non-ASCII
file arguments is limited to the current codepage [...]
This should be fixed, but will also require changes in cmdproxy.
The current limitation is not terribly bad anyway, since very
few, if any, Windows console programs that are likely to be
invoked by Emacs support UTF-16 encoded command lines.
I believe we're running into this limitation with git: staging a file
named 好.txt fails from magit[1] (I tried also with vc, same problem).
A quick way to see the problem is evaluating the call-process form
below, the output shows that the Chinese character has been transformed
into a space. This happens even if I execute 'chcp 65001' before
starting Emacs (a possible workaround I saw suggested in a few places).
The short file name trick doesn't help either.
(call-process "git" nil '(t t) nil
"-c" "alias.x=!x() { printf '%s' \"$1\" | od -tx1; }; x" "x"
"(好)")
0000000 28 20 29
0000003
As far as I can tell, git does support UTF-16 encoded command lines, as
demonstrated by the attached git-args.c, which produces the utf8
encoding of the character (this is also what the call-process form
produces when I run it on GNU/Linux):
C:\Users\npostavs\src\win32-args>.\git-args.exe
0000000 28 e5 a5 bd 29
0000005
git-args.c
Description: test program, C source
Am I correct that this problem is related the w32.c comment? It's not
clear to me what changes are needed in cmdproxy (and other places?) to
address it.
[1]: https://github.com/magit/magit/issues/3111
- bug#28180: [w32] Unicode characters in subprocess (git) arguments changed to space,
npostavs <=