Re: on eshell's encoding

[Yuri Khan]

On Wed, Jul 27, 2016 at 6:56 PM, Daniel Bastos <dbastos@toledo.com> wrote:

> I meant not being messed with.  I don't know anything about MS-Windows.
> In UNIX the creation of a new process by a shell is likely to call
> execve, which won't touch the caller strings passed in through the
> argv-argument.

Well Windows is a different beast entirely. The basic premise is the
same, in that the parent invokes CreateProcessW, passing a
UTF-16-encoded command line, and the child process invokes
GetCommandLineW and then optionally CommandLineToArgvW to split the
command line into arguments.

Problem is, most programs prefer to work internally with 8-bit-based
encodings, and the Win32 API makes it very easy by providing backward
compatibility wrapper functions CreateProcessA and GetCommandLineA,
which unfortunately convert from/to the ANSI or OEM encoding defined
by the locale. And there is no Win32 locale for which UTF-8 is either
the ANSI or the OEM encoding.

This one point makes it very difficult to use Windows in the Unix Way:
you get to worry about encodings on every process boundary.