Re: on eshell's encoding

[Daniel Bastos <dbastos@toledo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Bastos <dbastos@toledo.com>
>> Date: Wed, 27 Jul 2016 08:56:31 -0300
>> 
>> >> You're right.  This is MS-Windows.  But I thought MS-Windows would not
>> >> interfere here.  Why does it interfere?  I thought the messages would go
>> >> straight into git's ARGV.
>> >
>> > How can it go "straight"?  
>> 
>> 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.
>
> Like I said, Eshell is not a shell, it just pretends to be one.  It
> will eventually cause execve, or something like it, to be called, but
> before it, the command-line arguments will be encoded in the locale's
> encoding, since that's what execve expects.  This is true on Windows
> and on Unix alike.  

That's true of EMACS.  You're saying EMACS always encodes the command
line arguments.  But what I said about UNIX is that whatever execve
receives in argv[] will remain as such, which apparently is not the
MS-Windows behavior.

Precisely: if on UNIX I use EMACS to call /program/ with argv[] encoded
in X, then /program/ will definitely receive its argv[] as prepared by
EMACS.  That does not happen on MS-Windows.  EMACS encodes the command
line in utf-8, but /program/ receives it in another encoding.

This surprises me.  MS-Windows should not care what a program puts in
argv[].  I think it violates an important principle: an operating system
should help programs to communicate, but it should not care what they're
saying to each other.  That's an important principle UNIX has given us.

Even if I'm not totally correct now, I'm certainly better educated.
Thank you.