From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: on eshell's encoding
Date: Wed, 27 Jul 2016 19:22:05 +0300 [thread overview]
Message-ID: <83invrrqz6.fsf@gnu.org> (raw)
In-Reply-To: <CAP_d_8XaaFAXJj2TwmRtg8TLvWcTnQ6yOeqBF8-1EQBE8ryfWQ@mail.gmail.com> (message from Yuri Khan on Wed, 27 Jul 2016 19:15:45 +0600)
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 27 Jul 2016 19:15:45 +0600
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>
> 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.
So it isn't a different beast, really. Both on Unix and on Windows,
Emacs encodes the command line before passing it to system APIs. The
details differ, but not the basic idea.
> 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.
Nitpicking: always ANSI, never the OEM.
> And there is no Win32 locale for which UTF-8 is either the ANSI or
> the OEM encoding.
It's actually worse than that: the Windows locale implementation
doesn't support variable-length encodings, so UTF-8 cannot be a
locale's encoding, unless MS change their related runtime libraries in
a radical way.
> This one point makes it very difficult to use Windows in the Unix Way:
> you get to worry about encodings on every process boundary.
Same on Unix, unless you are willing to bet on UTF-8 being the
locale's codeset.
next prev parent reply other threads:[~2016-07-27 16:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 14:25 on eshell's encoding Daniel Bastos
2016-07-26 15:05 ` Eli Zaretskii
[not found] ` <mailman.2058.1469545530.26859.help-gnu-emacs@gnu.org>
2016-07-26 16:49 ` Daniel Bastos
2016-07-26 17:17 ` Eli Zaretskii
2016-07-26 18:26 ` Yuri Khan
2016-07-26 18:35 ` Eli Zaretskii
[not found] ` <mailman.2074.1469553449.26859.help-gnu-emacs@gnu.org>
2016-07-27 11:56 ` Daniel Bastos
2016-07-27 13:15 ` Yuri Khan
2016-07-27 16:22 ` Eli Zaretskii [this message]
2016-07-27 16:47 ` Yuri Khan
2016-07-27 17:12 ` Eli Zaretskii
2016-07-27 16:14 ` Eli Zaretskii
[not found] ` <mailman.2119.1469636078.26859.help-gnu-emacs@gnu.org>
2016-08-02 13:24 ` Daniel Bastos
2016-08-02 15:12 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83invrrqz6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).