Re: [PATCH 3/3] Inherit process output coding system to stderr process.

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mi., 4. Apr. 2018 um 15:39 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed,  4 Apr 2018 14:02:18 +0200
> > Cc: Philipp Stephani <phst@google.com>
> >
> > * src/process.c (Fmake_process): Inherit output coding system to
> > newly-created pipe process.
>
> I'm sorry, I don't understand the need for this "inheriting".  If the
> problem is that make-process and make-pipe-process use different logic
> to decide on the default coding-systems, then I think we should make
> them use the same logic, and then there will be no need for
> "inheriting".  Or is there something else I'm missing?
>

At least I would expect Emacs to use the same output encoding for both
standard output and error streams if an explicit output encoding is
provided, given that most external programs will also use the same encoding
for both streams. But currently Emacs uses the default encoding for the
standard error stream if it creates the pipe itself.


>
> > +        (let ((process (make-process
> > +                        :name "stderr-coding"
> > +                        :command (list shell-file-name
> shell-command-switch
> > +                                       (concat "echo -e
> '\\xC3\\xA4\\r'; "
> > +                                               "echo -e '\\xC3\\xB6\\r'
> >&2"))
>
> This shell command is non-portable.  I think even "echo -e" is not
> portable enough, let alone with hex escapes and the trailing \r.
> Can't we use Emacs instead?  There's also the ";" issue again.
>

Is it possible to write raw bytes to the standard output/error streams
using Emacs?


>
> > +          (should (equal (buffer-string) "\u00C3\u00B6\n"))))
> > +      (should (equal (buffer-string) "\u00C3\u00A4\n")))))
>
> Why not use literal characters here?  It will make the source more
> readable, IMO.
>

I don't care much, but using the character escapes here makes it obvious
that the output is decoded as Latin-1.

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]