Johannes Sixt:
Can you set the local codepage per program? (I don't know.)
The locale is set per thread, and gets reset when the program exits. So
setting the codepage to UTF-8 before outputting should work. That should
also work for displaying the log to the terminal if you have UTF-8 log
messages.
Converting it to wchar_t and using wprintf and similar should be safer,
though (and I have no idea what happens if you try to pipe the output to
something else).
- What encoding should 'ls-files' use for its output? Certainly not always
UTF-8: stdout should use the local code page so that the file names are
interpreted correctly by the terminal window (it expects the local code
page).
That is exactly why trying to mix "protocol" data ("plumbing" in Git's case)
and user output will always come back and bite you, one way or another. I
haven't really the faintest how pipes work with Unicode on Windows.
Somewhere along the line there will probably be some conversions, which
would cause interesting issues.
Better not use pipes, then. Heh. I sense that there is a slight problem with
the architecture of Git and trying to get it to behave on Windows... :-)
- What encoding should 'update-index' expect from its input? Can you be
sure that other programs generate UTF-8 output?
Theoretically, if all the internal stuff is hacked around to output Unicode,
and the thread codepage is set up to use UTF-8, it should "just work". And
if run directly from the shell, it should still be converted to whatever the
system is set up to emit. That would mean, however, that a Git program that
internally runs
git-foo | git-bar | git-gazonk
might behave differently compared to if a user would enter it on the
command-line.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
