From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 3/3] Inherit process output coding system to stderr process. Date: Sat, 07 Apr 2018 21:12:10 +0000 Message-ID: References: <20180404120218.257212-1-phst@google.com> <20180404120218.257212-3-phst@google.com> <83370b3xas.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="883d24f3eff8db6c57056948a04f" X-Trace: blaine.gmane.org 1523135431 2476 195.159.176.226 (7 Apr 2018 21:10:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Apr 2018 21:10:31 +0000 (UTC) Cc: phst@google.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 07 23:10:26 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4v6P-0000VT-Nc for ged-emacs-devel@m.gmane.org; Sat, 07 Apr 2018 23:10:25 +0200 Original-Received: from localhost ([::1]:53453 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4v8T-00061i-50 for ged-emacs-devel@m.gmane.org; Sat, 07 Apr 2018 17:12:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4v8L-00061K-Ar for emacs-devel@gnu.org; Sat, 07 Apr 2018 17:12:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4v8K-00007Y-8q for emacs-devel@gnu.org; Sat, 07 Apr 2018 17:12:25 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:47007) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f4v8I-00006T-Gl; Sat, 07 Apr 2018 17:12:22 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id j68-v6so4989306lfg.13; Sat, 07 Apr 2018 14:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xSCaVd/AtvfYrjuzltbT9BYbm6g1QXNMe3b2R9ZWvvI=; b=A5KEJ4/u9ym3z2jHEv51e20O0cGV3StgVywJ4gKU3MUgLa6n88oXyZH8OElONnK1JA 9oFBrwcdQVX9NVG/cnoWsUjNb6HjqasiS/xLRlAJs+P0JY32zjwARoAw3+E6UhHu50JS 3WvLnFlLv2KJY9HjX1ghziXjrIWhT9e1ojrlzSDfhNBW2N7OSYs1Jp+sraK4cz4/cbRk m9ClEbQTqwwHv2qHW6QaRAmZiXzgCixRediCw7oG1YMRyCs+4oqsPpFOhauoEEWpVKfz VQKzTLSnc0fTPg0ffI2V5slFaufo8WG6FTwYIQF0Vn3jLJikpZQrpJxOFHCtKJhAM0d/ 09Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xSCaVd/AtvfYrjuzltbT9BYbm6g1QXNMe3b2R9ZWvvI=; b=pcMg9EiBv/2PzDbCm8A2ThpFerA++hNBxvt5eYzYM+6cmIysI8Hi13+0RevfnrWM4w pWCTIR1UE2UfciZb1kTmMXerm1fphWRauFCN9juFq+skBOcCq8kLFeirfGfIVQ8SoRb6 N+xfMBLoq40c6zdfiSNKQfBN1gEDD6Yww0uZUdyCGuGzlKxfK+zXEpgTXLpA607giPR2 ouQ2KSFLzxHSFEO/8F27JZQdfQUYjBUuZHRYgvhZeMgCVAqAGqJA6vft8gOyf7qyNAGL akdLdeAWHnYp7HXtKBjja9EYY4x2QoSOoMksbq3ttY4c4wpR5be6JAtd5t79O0nbaHxa pkNA== X-Gm-Message-State: ALQs6tBbJVoXG17QrxT8/SH00VhWIDi0fIjC3x7eoKvtQwoEmG52WZiR wdtP5fCU31j89tfkcGS9fwcIRakYeqGT/MNsEDFvSQ== X-Google-Smtp-Source: AIpwx49pJzoG67WUIOFPi2tZUonKiYflGqzaSyCwfwNR81nK7yJiwy5noSLt9JSWH8zSm/yKIDqW/e+fbI712NkMEmk= X-Received: by 10.46.120.24 with SMTP id t24mr7068110ljc.68.1523135540848; Sat, 07 Apr 2018 14:12:20 -0700 (PDT) In-Reply-To: <83370b3xas.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224421 Archived-At: --883d24f3eff8db6c57056948a04f Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am Mi., 4. Apr. 2018 um 15:39 Uhr: > > From: Philipp Stephani > > Date: Wed, 4 Apr 2018 14:02:18 +0200 > > Cc: Philipp Stephani > > > > * 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. --883d24f3eff8db6c57056948a04f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mi., 4. Apr. 2018 um 15:39=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed,=C2=A0 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&qu= ot;.=C2=A0 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".=C2=A0 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 expl= icit output encoding is provided, given that most external programs will al= so use the same encoding for both streams. But currently Emacs uses the def= ault encoding for the standard error stream if it creates the pipe itself.<= /div>
=C2=A0

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((process (make-process
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 :name "stderr-coding"
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 :command (list shell-file-name shell-command-switch
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(conc= at "echo -e '\\xC3\\xA4\\r'; "
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"echo -e '\\xC3\\xB6\\r' >&2&qu= ot;))

This shell command is non-portable.=C2=A0 I think even "echo -e" = is not
portable enough, let alone with hex escapes and the trailing \r.
Can't we use Emacs instead?=C2=A0 There's also the ";" is= sue again.

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

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (should (equal (buffer-string) &qu= ot;\u00C3\u00B6\n"))))
> +=C2=A0 =C2=A0 =C2=A0 (should (equal (buffer-string) "\u00C3\u00A= 4\n")))))

Why not use literal characters here?=C2=A0 It will make the source more
readable, IMO.

I don't care much, b= ut using the character escapes here makes it obvious that the output is dec= oded as Latin-1.=C2=A0
--883d24f3eff8db6c57056948a04f--