GNU bug report logs - #47299
27.1; emacs --batch on MS-Windows does not immediately display `print'ed lines when invoked outside of the Command Prompt

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Ioannis Kappas <ioannis.kappas@HIDDEN>; Done: Lars Ingebrigtsen <larsi@HIDDEN>; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
bug marked as fixed in version 29.1, send any further explanations to 47299 <at> debbugs.gnu.org and Ioannis Kappas <ioannis.kappas@HIDDEN> Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 47299 <at> debbugs.gnu.org:


Received: (at 47299) by debbugs.gnu.org; 26 Jun 2022 18:24:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 26 14:24:16 2022
Received: from localhost ([127.0.0.1]:48973 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o5Wvg-0001aD-HX
	for submit <at> debbugs.gnu.org; Sun, 26 Jun 2022 14:24:16 -0400
Received: from quimby.gnus.org ([95.216.78.240]:57026)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1o5Wvc-0001Zu-Mz
 for 47299 <at> debbugs.gnu.org; Sun, 26 Jun 2022 14:24:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=J1OQ5DUfoV9GkjwZB1f9EvYVSTyp033+Czl30KAJsS4=; b=Ipsrs/MUiSSUF5UZhVZulNQX2W
 i15LDJDgGnp3CWj/Bj7mIAIZd4Fd+sYVqJKKUs/m6nl7eKgnIe3gL65rsObUGracOcj14KfHBrmOs
 MVCdHdCSBP+metcHPEX+02EplSymA0VvCznVBfaI3BhllxilKiy+DPrymCq+qwJ8WNBg=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1o5WvS-0004pT-Nv; Sun, 26 Jun 2022 20:24:05 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Ioannis Kappas <ioannis.kappas@HIDDEN>
Subject: Re: bug#47299: 27.1; emacs --batch on MS-Windows does not
 immediately display `print'ed lines when invoked outside of the Command
 Prompt
References: <CAMRHuGDzbc+L78NNJLdZ8VF_qRZ0eVnhtBsGdD9+kO8Hcy4dHw@HIDDEN>
 <CAMRHuGAzet7TkFFZpQ-piCqaTPbV3_+nkRk+QbmBTG7dP3DOEw@HIDDEN>
 <837dly85pq.fsf@HIDDEN>
 <CAMRHuGAP4UnLv-qCjHVGXgyBdreae=Xo4oUnr6WWaXbr+efJcw@HIDDEN>
Date: Sun, 26 Jun 2022 20:24:02 +0200
In-Reply-To: <CAMRHuGAP4UnLv-qCjHVGXgyBdreae=Xo4oUnr6WWaXbr+efJcw@HIDDEN>
 (Ioannis Kappas's message of "Tue, 23 Mar 2021 19:05:57 +0000")
Message-ID: <87czevb7wd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Ioannis Kappas <ioannis.kappas@HIDDEN> writes: >> What
 I can offer is to add a Lisp function to flush the stdout stream. >> Lisp
 programs that need to provide interactive experience could call >> that
 function where appropriate. >> > > yes please, [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47299
Cc: Eli Zaretskii <eliz@HIDDEN>, 47299 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Ioannis Kappas <ioannis.kappas@HIDDEN> writes:

>> What I can offer is to add a Lisp function to flush the stdout stream.
>> Lisp programs that need to provide interactive experience could call
>> that function where appropriate.
>>
>
> yes please, if you could do this at least we have a way to flush
> important messages out to stdout. I can review/test the patch once
> available.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was added as `flush-standard-output' in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47299; Package emacs. Full text available.

Message received at 47299 <at> debbugs.gnu.org:


Received: (at 47299) by debbugs.gnu.org; 23 Mar 2021 19:06:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 23 15:06:16 2021
Received: from localhost ([127.0.0.1]:33011 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOmM4-0007A2-Kk
	for submit <at> debbugs.gnu.org; Tue, 23 Mar 2021 15:06:16 -0400
Received: from mail-oi1-f174.google.com ([209.85.167.174]:33562)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lOmM1-00079l-Or
 for 47299 <at> debbugs.gnu.org; Tue, 23 Mar 2021 15:06:15 -0400
Received: by mail-oi1-f174.google.com with SMTP id w70so18164325oie.0
 for <47299 <at> debbugs.gnu.org>; Tue, 23 Mar 2021 12:06:13 -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=jNyxH2z5Kd5Dr8mQusI53J4XhL2lRKpXkkN2NHw3CWg=;
 b=dIt2mVjc4kYosN1rxWPGN0X52kEgiDrw28kZ2nxDvi5Fgz10N7nA31jzgzAPTqYVp4
 gXu2JTORftp1rVbQUPZW0+2SskenrK8xJnKh7hqlZFVDvKpYrhPKFRTHxv3Fv2gcQVgj
 rX9zpRbfAoCJ+R/NbDUMyujxC8tZL5QBiOubOesJGp+r58fa8hSrBXtwr/dl8oCLEL2L
 +DviWlC9+0ee1HnWj04j0Dk6ZtYVrwhgY1jKlVBzIoIBiv4DvWJAM64cRU3NfWePF3gs
 nPMgChtO3GBgTkZe0iUdJNy6a/nMmqfZ7PbXTY+gFx78XITsEWxbNizdEKm9PCP1WiAc
 vvDQ==
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=jNyxH2z5Kd5Dr8mQusI53J4XhL2lRKpXkkN2NHw3CWg=;
 b=bEnzx/VxbEVco6O815spgMvt8n3aTr8NSssXaXFj6b7QFiki2l1AXigkQYDWYSu0Ca
 9nG8lLj7ptW3PfTTJHinu127d1B0jB/ZTnuXcgr3z/LUOSHo+1TWCH3W5uYGmT8cJM0X
 78SXPgTp9yaIKvi9yFMOHxQJ8UdZuE7O0rBJyKJENlW1/J6NVjbjJjtQqZui9dxY9P5s
 Q52+VIt3zPO+GnZyuOaq27hre6U2iHy0aGGyPG5og8Z4PlP29WLq10TzRZYZ+XZ9zZMC
 s53xg7tGCxxCbsJXZn8SM/eURtQEMRjoXEpRmFJfPSIPUahX0Mv5TKEMCbp+mrvoUbOy
 gd9A==
X-Gm-Message-State: AOAM530TQrXzQ3cxpV+9wh7hCSpA3CpvrXyByC7wOttOFSE+179fp9JD
 KjdtdmG0dSy7CN0Cb/xY8vbJOw6W2oyRVKnGA4UsFhUsydw=
X-Google-Smtp-Source: ABdhPJwz6Gl7qx+wYhHalSpaTLy8kJY7P51Q1xBJvwYUh9BzLK/T5bDrfaMBGFBhg1HJB2DTeTZ1B6mi7koAPqZjkNQ=
X-Received: by 2002:aca:a8c3:: with SMTP id r186mr4366963oie.129.1616526368094; 
 Tue, 23 Mar 2021 12:06:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAMRHuGDzbc+L78NNJLdZ8VF_qRZ0eVnhtBsGdD9+kO8Hcy4dHw@HIDDEN>
 <CAMRHuGAzet7TkFFZpQ-piCqaTPbV3_+nkRk+QbmBTG7dP3DOEw@HIDDEN>
 <837dly85pq.fsf@HIDDEN>
In-Reply-To: <837dly85pq.fsf@HIDDEN>
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Tue, 23 Mar 2021 19:05:57 +0000
Message-ID: <CAMRHuGAP4UnLv-qCjHVGXgyBdreae=Xo4oUnr6WWaXbr+efJcw@HIDDEN>
Subject: Re: bug#47299: 27.1; emacs --batch on MS-Windows does not immediately
 display `print'ed lines when invoked outside of the Command Prompt
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47299
Cc: 47299 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Eli,

On Tue, Mar 23, 2021 at 11:33 AM Eli Zaretskii <eliz@HIDDEN> wrote:

> What I can offer is to add a Lisp function to flush the stdout stream.
> Lisp programs that need to provide interactive experience could call
> that function where appropriate.
>

yes please, if you could do this at least we have a way to flush
important messages out to stdout. I can review/test the patch once
available.

Thanks




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47299; Package emacs. Full text available.

Message received at 47299 <at> debbugs.gnu.org:


Received: (at 47299) by debbugs.gnu.org; 23 Mar 2021 11:33:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 23 07:33:41 2021
Received: from localhost ([127.0.0.1]:59717 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOfI4-0001xL-WE
	for submit <at> debbugs.gnu.org; Tue, 23 Mar 2021 07:33:41 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35826)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lOfI1-0001x6-8Z
 for 47299 <at> debbugs.gnu.org; Tue, 23 Mar 2021 07:33:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52139)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lOfHw-0000bW-0c; Tue, 23 Mar 2021 07:33:32 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1940
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lOfHv-0003qY-CJ; Tue, 23 Mar 2021 07:33:31 -0400
Date: Tue, 23 Mar 2021 13:33:37 +0200
Message-Id: <837dly85pq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ioannis Kappas <ioannis.kappas@HIDDEN>
In-Reply-To: <CAMRHuGAzet7TkFFZpQ-piCqaTPbV3_+nkRk+QbmBTG7dP3DOEw@HIDDEN>
 (message from Ioannis Kappas on Sun, 21 Mar 2021 21:06:28 +0000)
Subject: Re: bug#47299: 27.1;
 emacs --batch on MS-Windows does not immediately display `print'ed
 lines when invoked outside of the Command Prompt
References: <CAMRHuGDzbc+L78NNJLdZ8VF_qRZ0eVnhtBsGdD9+kO8Hcy4dHw@HIDDEN>
 <CAMRHuGAzet7TkFFZpQ-piCqaTPbV3_+nkRk+QbmBTG7dP3DOEw@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 47299
Cc: 47299 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Ioannis Kappas <ioannis.kappas@HIDDEN>
> Date: Sun, 21 Mar 2021 21:06:28 +0000
> 
> Similar to bug#46388 (27.1; emacs -batch does not output messages
> immediately when invoked outside of the command prompt) the issue
> stems from the expectation that stdout buffering should behave like in
> POSIX systems, which is not necessarily the case on 'windows-nt.

How stdout is buffered when it is not connected to a console device is
system-dependent, and any program that relies on a specific buffering
has a bug.

> stdout on windows-nt is either always unbuffered (when attached to the
> console) or fully-buffered (otherwise), while on 'gnu/linux I have
> experimentally found it to be line-buffered when invoked from the
> terminal or from another program such as Emacs M-x shell. I consider 
> this line-buffered behavior of 'gnu/linux to fall under the "interactive 
> device" of the standard mentioned above.
> 
> (When stdout is redirected to a file on 'gnu/linux, I found stdout to
> be fully-buffered having a 4096 buffer size).
> 
> (See standard-streams-test report @
> https://github.com/ikappaki/standard-streams-test for a tool that was
> written to investigate the buffering behavior of stderr on MS-Windows,
> i.e. unbuffered when attached to console, fully buffered
> otherwise. The same tool was modified to test stdout on a similar
> manner, which yielded exactly the same result).
> 
> Thus the difference in behavior as described in the bug report is due
> to stdout on 'windows-nt being fully buffered, rather than being line
> buffered as in 'gnu/linux.

The difference you observe is because on Windows we use pipes to
communicate with subprocesses, while on Posix platforms we by default
use PTYs, which are a kind of console device.  You can try using pipes
on GNU/Linux (by setting the process-connection-type variable), and
you will then see that the behavior on these two systems is similar,
not different.

> As such, two likely fixes are presented below, one that flushes stdout
> on a newline only iff stdout is attached to a pipe (as if it is the
> "interactive device" of the POSIX standard) but staying fully buffered
> otherwise (e.g. when output was redirected to a pipe or a socket), while
> the other fix always flushing stdout on a newline (a much simpler and less
> involved solution -- similar to the one in bug#46388 suggested by Mr. Eggert
> -- though not optimized for redirections to files).

I'm against both these changes.  Unconditionally flushing stdout each
newline is a non-starter, because it will slow down Lisp programs that
aren't interactive and need to send large buffers both ways.  At this
low level it cannot be known whether "the other end" of the pipe
expects interactivity or not.

What I can offer is to add a Lisp function to flush the stdout stream.
Lisp programs that need to provide interactive experience could call
that function where appropriate.

I don't see any other solution; doing what we do with stderr is
certainly inappropriate.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47299; Package emacs. Full text available.

Message received at 47299 <at> debbugs.gnu.org:


Received: (at 47299) by debbugs.gnu.org; 21 Mar 2021 21:06:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 21 17:06:47 2021
Received: from localhost ([127.0.0.1]:55552 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lO5Ha-0001eC-JC
	for submit <at> debbugs.gnu.org; Sun, 21 Mar 2021 17:06:47 -0400
Received: from mail-oi1-f180.google.com ([209.85.167.180]:35345)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lO5HX-0001dy-4q
 for 47299 <at> debbugs.gnu.org; Sun, 21 Mar 2021 17:06:45 -0400
Received: by mail-oi1-f180.google.com with SMTP id x2so11035233oiv.2
 for <47299 <at> debbugs.gnu.org>; Sun, 21 Mar 2021 14:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=HlBYhqxZSJA7A8x6nYm9An5qcarF64QBeRe51I30aeM=;
 b=rk6udBrVHUtJ5WFharS5rb072wC7tX4qjI0OiXP97l7c0xvbGPfNiNX0REAw33sl0M
 KcS7DBX1OSVWj7pjUWxG/ydbB0/PdzwvH9qbThPBgPIe8pq/cbdtQB49s56BsyAgont1
 8XWRcYC0rIFNeZEueKEz2Jkv3HTq0VThLn0MTgSFXWsBSSRSzflMJFIQCW9TrFKgMtGx
 vPAeHswtaIOgmWptP2zcgjL5HndeyTiv/r7nWL3Qmw4UXiP+M8UlRyJ2DApABH4XKoAR
 ND7gMc64AaHGCN6nKhnfE4QnyJIdakaae0mpGgnK4ic2cJcqGuKUYWGjiPFsnrO4G/AQ
 H4JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=HlBYhqxZSJA7A8x6nYm9An5qcarF64QBeRe51I30aeM=;
 b=o+Oh5r21fvh2r2Dm3Zjv7D8EZ8Oy92jKgNHS3j8dBvPN3K7wRRRF9YfQPtXyEiefCO
 gu0aayA3Qx7nJq0Q+Aa6wE7zqJTM7g9p2DAF/65nI1gS6xZxsHl/WgIZ3xBZFoMmGk3K
 HDfVxw3R3j+DTTlP776ccf/6hmh7o549kXDVn6VjCtE9OZASihLbMfS90UijVNErTPK5
 XWg0vM38pwECw05Dif89/7hnOsrdnBSk0uOO4JH+QW9Nb9AV/ijrP17f7mKgC3hz/ZGM
 AKIEjL0287MoWF3fpZCPBVl/NrC0geZ076UpwAiwknsgcpse02ovhEiAhvGsRD7LRuwo
 XUJw==
X-Gm-Message-State: AOAM531qzsOSQOyI2Xx4sd/PJT6Ed+VPfz84lRajEjxIzxHm+wWUixNC
 yXy2fiUMWeWCYJvPT46bHZRvu433SI3WU2TaToK8oeO3fjM=
X-Google-Smtp-Source: ABdhPJxGt/cDtnAZYMyjcSqUW0AlgbeDgMkz7H3wDEITPj6ZTCf6MX8LKPe8zXy0+PwHXeqAwqRZPvkmLuFmhdBQMxo=
X-Received: by 2002:aca:4b03:: with SMTP id y3mr8269564oia.78.1616360797254;
 Sun, 21 Mar 2021 14:06:37 -0700 (PDT)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Sun, 21 Mar 2021 21:06:28 +0000
Message-ID: <CAMRHuGAzet7TkFFZpQ-piCqaTPbV3_+nkRk+QbmBTG7dP3DOEw@HIDDEN>
Subject: 27.1; emacs --batch on MS-Windows does not immediately display
 `print'ed lines when invoked outside of the Command Prompt
To: 47299 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="00000000000026385905be12536c"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47299
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000026385905be12536c
Content-Type: text/plain; charset="UTF-8"

Analysis follows.

The `print' family of functions send their output to stdout by default
when ran in emacs --batch mode.

Similar to bug#46388 (27.1; emacs -batch does not output messages
immediately when invoked outside of the command prompt) the issue
stems from the expectation that stdout buffering should behave like in
POSIX systems, which is not necessarily the case on 'windows-nt.

The POSIX standard reads
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html)
under "stderr, stdin, stdout - standard I/O streams":

"""
...
At program start-up, three streams shall be predefined and need not be
opened explicitly: standard input (for reading conventional input),
standard output (for writing conventional output), and standard error
(for writing diagnostic output). When opened, the standard error
stream is not fully buffered; the standard input and standard output
streams are fully buffered if and only if the stream can be determined
not to refer to an interactive device.
...
"""

stdout on windows-nt is either always unbuffered (when attached to the
console) or fully-buffered (otherwise), while on 'gnu/linux I have
experimentally found it to be line-buffered when invoked from the
terminal or from another program such as Emacs M-x shell. I consider
this line-buffered behavior of 'gnu/linux to fall under the "interactive
device" of the standard mentioned above.

(When stdout is redirected to a file on 'gnu/linux, I found stdout to
be fully-buffered having a 4096 buffer size).

(See standard-streams-test report @
https://github.com/ikappaki/standard-streams-test for a tool that was
written to investigate the buffering behavior of stderr on MS-Windows,
i.e. unbuffered when attached to console, fully buffered
otherwise. The same tool was modified to test stdout on a similar
manner, which yielded exactly the same result).

Thus the difference in behavior as described in the bug report is due
to stdout on 'windows-nt being fully buffered, rather than being line
buffered as in 'gnu/linux.

As such, two likely fixes are presented below, one that flushes stdout
on a newline only iff stdout is attached to a pipe (as if it is the
"interactive device" of the POSIX standard) but staying fully buffered
otherwise (e.g. when output was redirected to a pipe or a socket), while
the other fix always flushing stdout on a newline (a much simpler and less
involved solution -- similar to the one in bug#46388 suggested by Mr. Eggert
-- though not optimized for redirections to files).

(Please note that the intention below is to change
src/print.c:printchar_to_stream(), which unless I missed something, is
only called from the `print' family of functions when Emacs is in
non-interactive mode).

_flush on newline when pipe_:
#+begin_src diff
5 files changed, 40 insertions(+)
src/print.c    |  2 ++
src/sysdep.c   | 21 +++++++++++++++++++++
src/sysstdio.h |  1 +
src/w32.c      | 13 +++++++++++++
src/w32.h      |  3 +++

modified   src/print.c
@@ -234,6 +234,8 @@ printchar_to_stream (unsigned int ch, FILE *stream)
       if (ASCII_CHAR_P (ch))
  {
    putc (ch, stream);

+          if (ch == '\n')
+            maybe_flush_stdout();
 #ifdef WINDOWSNT
    /* Send the output to a debugger (nothing happens if there
       isn't one).  */
modified   src/sysdep.c
@@ -2821,6 +2821,27 @@ errwrite (void const *buf, ptrdiff_t nbuf)
   fwrite_unlocked (buf, 1, nbuf, errstream ());
 }

+/* On windows, stdout is unbuffered when attached to the console but
+   fully buffered (4096 bytes) when redirected to a pipe (this buffer
+   is complementary to the pipe buffer).
+
+   Since Emacs --batch, at least on Windows, does not flush stdout it
+   means printing to standard output (for example with `princ' and its
+   variants) will not reach the parent process until at least this
+   process exits or the stream buffer is full, resulting to a very
+   poor interaction with the parent, contrary to how 'gnu/linux stdout
works.
+
+   We thus provide an interface to these functions to flush stdout
+   when has been redirected to a pipe.
+*/
+void maybe_flush_stdout (void)
+{
+#ifdef WINDOWSNT
+  if (is_stdout_pipe())
+    fflush_unlocked(stdout);
+#endif /* WINDOWSNT */
+}
+
 /* Close standard output and standard error, reporting any write
    errors as best we can.  This is intended for use with atexit.  */
 void
modified   src/sysstdio.h
@@ -27,6 +27,7 @@ #define EMACS_SYSSTDIO_H
 #include "unlocked-io.h"

 extern FILE *emacs_fopen (char const *, char const *);
+extern void maybe_flush_stdout (void);
 extern void errputc (int);
 extern void errwrite (void const *, ptrdiff_t);
 extern void close_output_streams (void);
modified   src/w32.c
@@ -10190,6 +10190,12 @@ term_ntproc (int ignored)
   term_w32select ();
 }

+static bool _is_stdout_pipe = false;
+bool is_stdout_pipe (void)
+{
+  return _is_stdout_pipe;
+}
+
 void
 init_ntproc (int dumping)
 {
@@ -10268,6 +10274,13 @@ init_ntproc (int dumping)
     _fdopen (2, "w");
   }

+  HANDLE soh = (HANDLE)_get_osfhandle(_fileno(stdout));
+  _is_stdout_pipe =
+    /* is pipe (anonymous, named or socket)*/
+    GetFileType(soh) == FILE_TYPE_PIPE
+    /* and is definitely not a socket */
+    && GetNamedPipeInfo(soh, NULL, NULL, NULL, NULL);
+
   /* unfortunately, atexit depends on implementation of malloc */
   /* atexit (term_ntproc); */
   if (!dumping)
modified   src/w32.h
@@ -170,6 +170,9 @@ #define FILE_SERIAL             0x0800
 extern HANDLE maybe_load_unicows_dll (void);
 extern void globals_of_w32 (void);

+/* return whether standard output is redirected to a pipe. */
+extern bool is_stdout_pipe (void);
+
 extern void term_timers (void);
 extern void init_timers (void);
#+end_src

#+begin_src diff
  1 file changed, 8 insertions(+)
  src/print.c | 8 ++++++++

  modified   src/print.c
  @@ -235,6 +235,14 @@ printchar_to_stream (unsigned int ch, FILE *stream)
          {
            putc (ch, stream);
   #ifdef WINDOWSNT
  +          /* Flush stdout after outputting a newline since stdout is
  +             fully buffered when redirected to a pipe, contrary to
  +             POSIX when attached to an "interactive device" (see
  +             "stderr, stdin, stdout - standard I/O streams" in IEEE
  +             1003.1-2017) */
  +          if (ch == '\n' && stream == stdout)
  +            fflush_unlocked(stdout);
  +
            /* Send the output to a debugger (nothing happens if there
               isn't one).  */
            if (print_output_debug_flag && stream == stderr)

#+end_src

Feel free to modify/replace the above two as you find appropriate
(especially the excessive comments).

Thanks

--00000000000026385905be12536c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><font face=3D"monospace">Analysis fo=
llows.</font></div><div><font face=3D"monospace"><br></font></div><div><fon=
t face=3D"monospace">The `print&#39; family of functions send their output =
to stdout by default</font></div><div><font face=3D"monospace">when ran in =
emacs --batch mode.</font></div><div><font face=3D"monospace"><br></font></=
div><div><font face=3D"monospace">Similar to bug#46388 (27.1; emacs -batch =
does not output messages</font></div><div><font face=3D"monospace">immediat=
ely when invoked outside of the command prompt) the issue</font></div><div>=
<font face=3D"monospace">stems from the expectation that stdout buffering s=
hould behave like in</font></div><div><font face=3D"monospace">POSIX system=
s, which is not necessarily the case on &#39;windows-nt.</font></div><div><=
font face=3D"monospace"><br></font></div><div><font face=3D"monospace">The =
POSIX standard reads</font></div><div><font face=3D"monospace">(<a href=3D"=
https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html">http=
s://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html</a>)</fon=
t></div><div><font face=3D"monospace">under &quot;stderr, stdin, stdout - s=
tandard I/O streams&quot;:</font></div><div><font face=3D"monospace"><br></=
font></div><div><font face=3D"monospace">&quot;&quot;&quot;</font></div><di=
v><font face=3D"monospace">...</font></div><div><font face=3D"monospace">At=
 program start-up, three streams shall be predefined and need not be</font>=
</div><div><font face=3D"monospace">opened explicitly: standard input (for =
reading conventional input),</font></div><div><font face=3D"monospace">stan=
dard output (for writing conventional output), and standard error</font></d=
iv><div><font face=3D"monospace">(for writing diagnostic output). When open=
ed, the standard error</font></div><div><font face=3D"monospace">stream is =
not fully buffered; the standard input and standard output</font></div><div=
><font face=3D"monospace">streams are fully buffered if and only if the str=
eam can be determined</font></div><div><font face=3D"monospace">not to refe=
r to an interactive device.</font></div><div><font face=3D"monospace">...</=
font></div><div><font face=3D"monospace">&quot;&quot;&quot;</font></div><di=
v><font face=3D"monospace"><br></font></div><div><font face=3D"monospace">s=
tdout on windows-nt is either always unbuffered (when attached to the</font=
></div><div><font face=3D"monospace">console) or fully-buffered (otherwise)=
, while on &#39;gnu/linux I have</font></div><div><font face=3D"monospace">=
experimentally found it to be line-buffered when invoked from the</font></d=
iv><div><font face=3D"monospace">terminal or from another program such as E=
macs M-x=C2=A0</font><span style=3D"font-family:monospace">shell. I conside=
r=C2=A0</span></div><div><span style=3D"font-family:monospace">this line-bu=
ffered behavior of &#39;gnu/linux to fall under the=C2=A0</span><span style=
=3D"font-family:monospace">&quot;interactive=C2=A0</span></div><div><span s=
tyle=3D"font-family:monospace">device&quot; of=C2=A0</span><span style=3D"f=
ont-family:monospace">the standard mentioned above.</span></div><div><font =
face=3D"monospace"><br></font></div><div><font face=3D"monospace">(When std=
out is redirected to a file on &#39;gnu/linux, I found stdout to</font></di=
v><div><font face=3D"monospace">be fully-buffered having a 4096 buffer size=
).</font></div><div><font face=3D"monospace"><br></font></div><div><font fa=
ce=3D"monospace">(See standard-streams-test report @</font></div><div><font=
 face=3D"monospace"><a href=3D"https://github.com/ikappaki/standard-streams=
-test">https://github.com/ikappaki/standard-streams-test</a> for a tool tha=
t was</font></div><div><font face=3D"monospace">written to investigate the =
buffering behavior of stderr on MS-Windows,</font></div><div><font face=3D"=
monospace">i.e. unbuffered when attached to console, fully buffered</font><=
/div><div><font face=3D"monospace">otherwise. The same tool was modified to=
 test stdout on a similar</font></div><div><font face=3D"monospace">manner,=
 which yielded exactly the same result).</font></div><div><font face=3D"mon=
ospace"><br></font></div><div><font face=3D"monospace">Thus the difference =
in behavior as described in the bug report is due</font></div><div><font fa=
ce=3D"monospace">to stdout on &#39;windows-nt being fully buffered, rather =
than being line</font></div><div><font face=3D"monospace">buffered as in &#=
39;gnu/linux.</font></div><div><font face=3D"monospace"><br></font></div><d=
iv><font face=3D"monospace">As such, two likely fixes are presented below, =
one that flushes stdout</font></div><div><font face=3D"monospace">on a newl=
ine only iff stdout is attached to a pipe (as if it is the</font></div><div=
><font face=3D"monospace">&quot;interactive device&quot; of the POSIX stand=
ard) but staying fully buffered</font></div><div><font face=3D"monospace">o=
therwise (e.g. when output was redirected to a pipe or a socket), while</fo=
nt></div><div><font face=3D"monospace">the other fix always flushing stdout=
 on a newline (a much simpler and less</font></div><div><font face=3D"monos=
pace">involved solution -- similar to the one in bug#46388 suggested by Mr.=
 Eggert</font></div><div><font face=3D"monospace">-- though not optimized f=
or redirections to files).</font></div><div><font face=3D"monospace"><br></=
font></div><div><font face=3D"monospace">(Please note that the intention be=
low is to change</font></div><div><font face=3D"monospace">src/print.c:prin=
tchar_to_stream(), which unless I missed something, is</font></div><div><fo=
nt face=3D"monospace">only called from the `print&#39; family of functions =
when Emacs is in</font></div><div><font face=3D"monospace">non-interactive =
mode).</font></div><div><font face=3D"monospace"><br></font></div><div><fon=
t face=3D"monospace">_flush on newline when pipe_:</font></div><div><font f=
ace=3D"monospace">#+begin_src diff</font></div><div><font face=3D"monospace=
">5 files changed, 40 insertions(+)</font></div><div><font face=3D"monospac=
e">src/print.c=C2=A0 =C2=A0 |=C2=A0 2 ++</font></div><div><font face=3D"mon=
ospace">src/sysdep.c=C2=A0 =C2=A0| 21 +++++++++++++++++++++</font></div><di=
v><font face=3D"monospace">src/sysstdio.h |=C2=A0 1 +</font></div><div><fon=
t face=3D"monospace">src/w32.c=C2=A0 =C2=A0 =C2=A0 | 13 +++++++++++++</font=
></div><div><font face=3D"monospace">src/w32.h=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =
3 +++</font></div><div><font face=3D"monospace"><br></font></div><div><font=
 face=3D"monospace">modified=C2=A0 =C2=A0src/print.c</font></div><div><font=
 face=3D"monospace">@@ -234,6 +234,8 @@ printchar_to_stream (unsigned int c=
h, FILE *stream)</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0if (ASCII_CHAR_P (ch))</font></div><div><font face=3D"monospac=
e">=C2=A0<span style=3D"white-space:pre">	</span>{</font></div><div><font f=
ace=3D"monospace">=C2=A0<span style=3D"white-space:pre">	</span>=C2=A0 putc=
 (ch, stream);</font></div><div><font face=3D"monospace"><br></font></div><=
div><font face=3D"monospace">+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ch =3D=
=3D &#39;\n&#39;)</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 maybe_flush_stdout();</font></div><div><font fa=
ce=3D"monospace">=C2=A0#ifdef WINDOWSNT</font></div><div><font face=3D"mono=
space">=C2=A0<span style=3D"white-space:pre">	</span>=C2=A0 /* Send the out=
put to a debugger (nothing happens if there</font></div><div><font face=3D"=
monospace">=C2=A0<span style=3D"white-space:pre">	</span>=C2=A0 =C2=A0 =C2=
=A0isn&#39;t one).=C2=A0 */</font></div><div><font face=3D"monospace">modif=
ied=C2=A0 =C2=A0src/sysdep.c</font></div><div><font face=3D"monospace">@@ -=
2821,6 +2821,27 @@ errwrite (void const *buf, ptrdiff_t nbuf)</font></div><=
div><font face=3D"monospace">=C2=A0 =C2=A0fwrite_unlocked (buf, 1, nbuf, er=
rstream ());</font></div><div><font face=3D"monospace">=C2=A0}</font></div>=
<div><font face=3D"monospace">=C2=A0</font></div><div><font face=3D"monospa=
ce">+/* On windows, stdout is unbuffered when attached to the console but</=
font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0fully buffered (4096=
 bytes) when redirected to a pipe (this buffer</font></div><div><font face=
=3D"monospace">+=C2=A0 =C2=A0is complementary to the pipe buffer).</font></=
div><div><font face=3D"monospace">+</font></div><div><font face=3D"monospac=
e">+=C2=A0 =C2=A0Since Emacs --batch, at least on Windows, does not flush s=
tdout it</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0means prin=
ting to standard output (for example with `princ&#39; and its</font></div><=
div><font face=3D"monospace">+=C2=A0 =C2=A0variants) will not reach the par=
ent process until at least this</font></div><div><font face=3D"monospace">+=
=C2=A0 =C2=A0process exits or the stream buffer is full, resulting to a ver=
y</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0poor interaction =
with the parent, contrary to how &#39;gnu/linux stdout works.</font></div><=
div><font face=3D"monospace">+</font></div><div><font face=3D"monospace">+=
=C2=A0 =C2=A0We thus provide an interface to these functions to flush stdou=
t</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0when has been red=
irected to a pipe.</font></div><div><font face=3D"monospace">+*/</font></di=
v><div><font face=3D"monospace">+void maybe_flush_stdout (void)</font></div=
><div><font face=3D"monospace">+{</font></div><div><font face=3D"monospace"=
>+#ifdef WINDOWSNT</font></div><div><font face=3D"monospace">+=C2=A0 if (is=
_stdout_pipe())</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0 ff=
lush_unlocked(stdout);</font></div><div><font face=3D"monospace">+#endif /*=
 WINDOWSNT */</font></div><div><font face=3D"monospace">+}</font></div><div=
><font face=3D"monospace">+</font></div><div><font face=3D"monospace">=C2=
=A0/* Close standard output and standard error, reporting any write</font><=
/div><div><font face=3D"monospace">=C2=A0 =C2=A0 errors as best we can.=C2=
=A0 This is intended for use with atexit.=C2=A0 */</font></div><div><font f=
ace=3D"monospace">=C2=A0void</font></div><div><font face=3D"monospace">modi=
fied=C2=A0 =C2=A0src/sysstdio.h</font></div><div><font face=3D"monospace">@=
@ -27,6 +27,7 @@ #define EMACS_SYSSTDIO_H</font></div><div><font face=3D"mo=
nospace">=C2=A0#include &quot;unlocked-io.h&quot;</font></div><div><font fa=
ce=3D"monospace">=C2=A0</font></div><div><font face=3D"monospace">=C2=A0ext=
ern FILE *emacs_fopen (char const *, char const *);</font></div><div><font =
face=3D"monospace">+extern void maybe_flush_stdout (void);</font></div><div=
><font face=3D"monospace">=C2=A0extern void errputc (int);</font></div><div=
><font face=3D"monospace">=C2=A0extern void errwrite (void const *, ptrdiff=
_t);</font></div><div><font face=3D"monospace">=C2=A0extern void close_outp=
ut_streams (void);</font></div><div><font face=3D"monospace">modified=C2=A0=
 =C2=A0src/w32.c</font></div><div><font face=3D"monospace">@@ -10190,6 +101=
90,12 @@ term_ntproc (int ignored)</font></div><div><font face=3D"monospace=
">=C2=A0 =C2=A0term_w32select ();</font></div><div><font face=3D"monospace"=
>=C2=A0}</font></div><div><font face=3D"monospace">=C2=A0</font></div><div>=
<font face=3D"monospace">+static bool _is_stdout_pipe =3D false;</font></di=
v><div><font face=3D"monospace">+bool is_stdout_pipe (void)</font></div><di=
v><font face=3D"monospace">+{</font></div><div><font face=3D"monospace">+=
=C2=A0 return _is_stdout_pipe;</font></div><div><font face=3D"monospace">+}=
</font></div><div><font face=3D"monospace">+</font></div><div><font face=3D=
"monospace">=C2=A0void</font></div><div><font face=3D"monospace">=C2=A0init=
_ntproc (int dumping)</font></div><div><font face=3D"monospace">=C2=A0{</fo=
nt></div><div><font face=3D"monospace">@@ -10268,6 +10274,13 @@ init_ntproc=
 (int dumping)</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=
=A0_fdopen (2, &quot;w&quot;);</font></div><div><font face=3D"monospace">=
=C2=A0 =C2=A0}</font></div><div><font face=3D"monospace">=C2=A0</font></div=
><div><font face=3D"monospace">+=C2=A0 HANDLE soh =3D (HANDLE)_get_osfhandl=
e(_fileno(stdout));</font></div><div><font face=3D"monospace">+=C2=A0 _is_s=
tdout_pipe =3D</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0 /* =
is pipe (anonymous, named or socket)*/</font></div><div><font face=3D"monos=
pace">+=C2=A0 =C2=A0 GetFileType(soh) =3D=3D FILE_TYPE_PIPE</font></div><di=
v><font face=3D"monospace">+=C2=A0 =C2=A0 /* and is definitely not a socket=
 */</font></div><div><font face=3D"monospace">+=C2=A0 =C2=A0 &amp;&amp; Get=
NamedPipeInfo(soh, NULL, NULL, NULL, NULL);</font></div><div><font face=3D"=
monospace">+</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0/* unfo=
rtunately, atexit depends on implementation of malloc */</font></div><div><=
font face=3D"monospace">=C2=A0 =C2=A0/* atexit (term_ntproc); */</font></di=
v><div><font face=3D"monospace">=C2=A0 =C2=A0if (!dumping)</font></div><div=
><font face=3D"monospace">modified=C2=A0 =C2=A0src/w32.h</font></div><div><=
font face=3D"monospace">@@ -170,6 +170,9 @@ #define FILE_SERIAL=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0800</font></div><div><font face=3D=
"monospace">=C2=A0extern HANDLE maybe_load_unicows_dll (void);</font></div>=
<div><font face=3D"monospace">=C2=A0extern void globals_of_w32 (void);</fon=
t></div><div><font face=3D"monospace">=C2=A0</font></div><div><font face=3D=
"monospace">+/* return whether standard output is redirected to a pipe. */<=
/font></div><div><font face=3D"monospace">+extern bool is_stdout_pipe (void=
);</font></div><div><font face=3D"monospace">+</font></div><div><font face=
=3D"monospace">=C2=A0extern void term_timers (void);</font></div><div><font=
 face=3D"monospace">=C2=A0extern void init_timers (void);</font></div><div>=
<font face=3D"monospace">#+end_src</font></div><div><font face=3D"monospace=
"><br></font></div><div><font face=3D"monospace">#+begin_src diff</font></d=
iv><div><font face=3D"monospace">=C2=A0 1 file changed, 8 insertions(+)</fo=
nt></div><div><font face=3D"monospace">=C2=A0 src/print.c | 8 ++++++++</fon=
t></div><div><font face=3D"monospace"><br></font></div><div><font face=3D"m=
onospace">=C2=A0 modified=C2=A0 =C2=A0src/print.c</font></div><div><font fa=
ce=3D"monospace">=C2=A0 @@ -235,6 +235,14 @@ printchar_to_stream (unsigned =
int ch, FILE *stream)</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 {</font></div><div><font face=3D"monospace">=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 putc (ch, stream);</font></div><div><fo=
nt face=3D"monospace">=C2=A0 =C2=A0#ifdef WINDOWSNT</font></div><div><font =
face=3D"monospace">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Flush stdo=
ut after outputting a newline since stdout is</font></div><div><font face=
=3D"monospace">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0full=
y buffered when redirected to a pipe, contrary to</font></div><div><font fa=
ce=3D"monospace">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PO=
SIX when attached to an &quot;interactive device&quot; (see</font></div><di=
v><font face=3D"monospace">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0&quot;stderr, stdin, stdout - standard I/O streams&quot; in IEEE<=
/font></div><div><font face=3D"monospace">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A01003.1-2017) */</font></div><div><font face=3D"mono=
space">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ch =3D=3D &#39;\n&#39=
; &amp;&amp; stream =3D=3D stdout)</font></div><div><font face=3D"monospace=
">=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fflush_unlocked(stdout)=
;</font></div><div><font face=3D"monospace">=C2=A0 +</font></div><div><font=
 face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Send the o=
utput to a debugger (nothing happens if there</font></div><div><font face=
=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn&#=
39;t one).=C2=A0 */</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (print_output_debug_flag &amp;&amp; stream =
=3D=3D stderr)</font></div><div><font face=3D"monospace"><br></font></div><=
div><font face=3D"monospace">#+end_src</font></div><div><font face=3D"monos=
pace"><br></font></div><div><font face=3D"monospace">Feel free to modify/re=
place the above two as you find appropriate</font></div><div><font face=3D"=
monospace">(especially the excessive comments).</font></div><div><font face=
=3D"monospace"><br></font></div><div><font face=3D"monospace">Thanks</font>=
</div><div><br></div></div></div>

--00000000000026385905be12536c--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47299; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 21 Mar 2021 19:45:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 21 15:45:42 2021
Received: from localhost ([127.0.0.1]:55519 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lO414-0008Aq-4t
	for submit <at> debbugs.gnu.org; Sun, 21 Mar 2021 15:45:42 -0400
Received: from lists.gnu.org ([209.51.188.17]:33482)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lO40y-0008Ae-Kp
 for submit <at> debbugs.gnu.org; Sun, 21 Mar 2021 15:45:36 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60240)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1lO40y-0007Zm-BK
 for bug-gnu-emacs@HIDDEN; Sun, 21 Mar 2021 15:45:32 -0400
Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:38749)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1lO40w-0001l3-Gg
 for bug-gnu-emacs@HIDDEN; Sun, 21 Mar 2021 15:45:32 -0400
Received: by mail-ot1-x32a.google.com with SMTP id
 w21-20020a9d63950000b02901ce7b8c45b4so13880899otk.5
 for <bug-gnu-emacs@HIDDEN>; Sun, 21 Mar 2021 12:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=OhHu69TFa2mwrAkP7RjfLyocoS6Zm5wkhiuX4t8+Thk=;
 b=rgoQoZSfyjsIjv6Hc66DYFtTF9VfKYquQb07J7GoPcuO9Pe4evF+iDtzguFqitplVI
 9FWFVqlnFTeE0wXYMXtnbaDyrlSyIcStqP6sLltpRkqKp4MYnVxhmdxNwVQfxb5YG2xe
 zN9Q5JZrrWPiFFVY8JI/U1GxwG+j1kx2bBrYDTz3knO5Dz/BDWf77oLE9h8u+c153H/b
 x7Gby3LqCnCjjByCZ8e30kUF0LQAxsxU56OPcIksPOyuORHb6eX8wY39TTXlUV+2DxH/
 1cPBtWXT3xNnG4VJ/Pvi7tYncGhQHww1VfVjx/U9k0yF/Q7w5u5iiRFCxuvA4mHv8F5s
 sxXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=OhHu69TFa2mwrAkP7RjfLyocoS6Zm5wkhiuX4t8+Thk=;
 b=H/afW6up878aJXHxVELpleiXroA9DqekDba0NXsWfcHe3y72/PgUSTPl3ic3xtZKpg
 6FgOxiVO9I2yoyOcA7IR3eLmHekSIp4S+xWgjpniA5BqsFweR1f/sba2RmFonFsbitcW
 P7JPZxBUEChCcFvLGUva4QBxOX6eR73VQU3uCr603bUhRgCJFZ1TBVB0c1jR3k9FQeQO
 Ozo6/xsu+oMszhxO+pY4/B65fkq/bj7JPnpnGLL7tfCBgAt/VNSScRmufYdaqVcPvHou
 RKogX+VAx+vTpaHVVtcu/lwnHzGP3oEw3PMYuhjuj4cNBf33G8QnJ0PxYpKXLmiATNBr
 5NFQ==
X-Gm-Message-State: AOAM530+NiOuhnF0dZxntv9AB29udqryV0CyZyCxl9F2lahuObjwqBCe
 HkX2jBBoBn28C5zBXkjD+JFQfI3lpcsevZ3eIHfOtAGBsa8=
X-Google-Smtp-Source: ABdhPJxAMzr2iRl9xoI6I0v9UKsfdu/+4SMGEuoO2IQuPGFoSn7b5KydXCgyFQyEviAQumMxFJRMHADdu/9JnGsGmEE=
X-Received: by 2002:a05:6830:1288:: with SMTP id
 z8mr9435003otp.5.1616355928743; 
 Sun, 21 Mar 2021 12:45:28 -0700 (PDT)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Sun, 21 Mar 2021 19:45:19 +0000
Message-ID: <CAMRHuGDzbc+L78NNJLdZ8VF_qRZ0eVnhtBsGdD9+kO8Hcy4dHw@HIDDEN>
Subject: 27.1; emacs --batch on MS-Windows does not immediately display
 `print'ed lines when invoked outside of the Command Prompt
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/mixed; boundary="000000000000f6b2e105be1130d3"
Received-SPF: pass client-ip=2607:f8b0:4864:20::32a;
 envelope-from=ioannis.kappas@HIDDEN; helo=mail-ot1-x32a.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

--000000000000f6b2e105be1130d3
Content-Type: multipart/alternative; boundary="000000000000f6b2de05be1130d1"

--000000000000f6b2de05be1130d1
Content-Type: text/plain; charset="UTF-8"

emacs --batch behaves differently on MS-Windows vs. GNU/Linux (at
least) while `print'ing values out, leading to poor user experience
and unexpected behavior.

`print' and its variants (e.g. `prin1' and `princ'), output the printed
representation of an OBJECT passed in as an argument.

A user expects to see `print'ed output from a --batch program as it is
printed out, but output on 'windows-nt when Emacs --batch program is
invoked outside of Command Prompt is only displayed after the
accumulated `print'ed output reaches a certain threshold (4096 bytes)
or the program exits, leading to a poor user experience.

This is unlike the behavior when the program is invoked from the
Command Prompt (output is displayed immediately) or when the program
is invoked from a terminal on 'gnu/linux (output is displayed after a
newline is encountered).

For example, the following is expected to print out immediately a
newline followed by 1 followed by a newline (i.e. "\n1\n"):

: emacs -Q --batch --eval "(progn (princ 1) (sleep-for 5))"

but when invoked from outside the Command Prompt (e.g. M-x shell), the
output is only displayed after 5 seconds (i.e. while the program is
about to exit).

| `system-type' | invoked-from   | result          |
|---------------+----------------+-----------------|
| 'windows-nt   | Command Prompt | immediately     |
| 'windows-nt   | M-x shell      | after 5 seconds |
| 'gnu/linux    | terminal       | immediately     |
| 'gnu/linux    | M-x shell      | immediately     |

Further more, the behavior is even worse when emacs --batch is invoked
programmatically by Emacs itself. If the accumulated `print'ed output
length is relatively small (less than 4096 bytes), no output is
received by the parent Emacs process, unlikely that on 'gnu/linux
where output is received while lines are `print'ed out.

The attached `ert' test demonstrates the above point using `princ',
whereby the parent Emacs process receives the "hi\n" output from the
emacs --batch child process on 'gnu/linux as expected, but it receives
nothing on 'windows-nt.

: emacs -Q --batch -l ert -l batch-print-test.el -f ert-run-tests-batch

| `system-type' | result      |
|---------------+-------------|
| 'windows-nt   | fail        |
| 'gnu/linux    | pass        |

Analysis with likely fixes to follow.

(This report is similar to bug#46388)

Configured using:
 'configure --prefix=/mingw64 --build=x86_64-w64-mingw32 --with-modules
 --without-dbus --without-compress-install 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe' CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1
 'LDFLAGS=-pipe
 -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high''

--000000000000f6b2de05be1130d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><font face=3D"monospace">emacs --batch behaves differently=
 on MS-Windows vs. GNU/Linux (at<br>least) while `print&#39;ing values out,=
 leading to poor user experience<br>and unexpected behavior.<br><br>`print&=
#39; and its variants (e.g. `prin1&#39; and `princ&#39;), output the printe=
d=C2=A0</font><div><font face=3D"monospace">representation of an OBJECT pas=
sed in as an argument.<br><br>A user expects to see `print&#39;ed output fr=
om a --batch program as it is<br>printed out, but output on &#39;windows-nt=
 when Emacs --batch program is<br>invoked outside of Command Prompt is only=
 displayed after the<br>accumulated `print&#39;ed output reaches a certain =
threshold (4096 bytes)<br>or the program exits, leading to a poor user expe=
rience.<br><br>This is unlike the behavior when the program is invoked from=
 the<br>Command Prompt (output is displayed immediately) or when the progra=
m<br>is invoked from a terminal on &#39;gnu/linux (output is displayed afte=
r a<br>newline is encountered).<br><br>For example, the following is expect=
ed to print out immediately a<br>newline followed by 1 followed by a newlin=
e (i.e. &quot;\n1\n&quot;):<br><br>: emacs -Q --batch --eval &quot;(progn (=
princ 1) (sleep-for 5))&quot;<br><br>but when invoked from outside the Comm=
and Prompt (e.g. M-x shell), the<br>output is only displayed after 5 second=
s (i.e. while the program is<br>about to exit).<br><br>| `system-type&#39; =
| invoked-from =C2=A0 | result =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>|----=
-----------+----------------+-----------------|<br>| &#39;windows-nt =C2=A0=
 | Command Prompt | immediately =C2=A0 =C2=A0 |<br>| &#39;windows-nt =C2=A0=
 | M-x shell =C2=A0 =C2=A0 =C2=A0| after 5 seconds |<br>| &#39;gnu/linux =
=C2=A0 =C2=A0| terminal =C2=A0 =C2=A0 =C2=A0 | immediately =C2=A0 =C2=A0 |<=
br>| &#39;gnu/linux =C2=A0 =C2=A0| M-x shell =C2=A0 =C2=A0 =C2=A0| immediat=
ely =C2=A0 =C2=A0 |<br><br>Further more, the behavior is even worse when em=
acs --batch is invoked<br>programmatically=C2=A0by Emacs itself. If the acc=
umulated `print&#39;ed output<br>length is relatively small (less than 4096=
 bytes), no output is<br>received by the parent Emacs process, unlikely tha=
t on &#39;gnu/linux<br>where output is received while lines are `print&#39;=
ed out.<br><br>The attached `ert&#39; test demonstrates the above point usi=
ng `princ&#39;,<br>whereby the parent Emacs process receives the &quot;hi\n=
&quot; output from the<br>emacs --batch child process on &#39;gnu/linux as =
expected, but it receives<br>nothing on &#39;windows-nt.<br><br>: emacs -Q =
--batch -l ert -l batch-print-test.el -f ert-run-tests-batch<br><br>| `syst=
em-type&#39; | result =C2=A0 =C2=A0 =C2=A0|<br>|---------------+-----------=
--|<br>| &#39;windows-nt =C2=A0 | fail =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>| &#=
39;gnu/linux =C2=A0 =C2=A0| pass =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br><br>Analys=
is with likely fixes to follow.<br><br>(This report is similar to bug#46388=
)</font><div><font face=3D"monospace"><br></font></div><div><font face=3D"m=
onospace">Configured using:<br>=C2=A0&#39;configure --prefix=3D/mingw64 --b=
uild=3Dx86_64-w64-mingw32 --with-modules<br>=C2=A0--without-dbus --without-=
compress-install &#39;CFLAGS=3D-march=3Dx86-64<br>=C2=A0-mtune=3Dgeneric -O=
2 -pipe&#39; CPPFLAGS=3D-D__USE_MINGW_ANSI_STDIO=3D1<br>=C2=A0&#39;LDFLAGS=
=3D-pipe<br>=C2=A0-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-=
image-base-high&#39;&#39;</font><br></div></div></div>

--000000000000f6b2de05be1130d1--

--000000000000f6b2e105be1130d3
Content-Type: application/octet-stream; name="batch-print-test.el"
Content-Disposition: attachment; filename="batch-print-test.el"
Content-Transfer-Encoding: base64
Content-ID: <f_kmjk79i10>
X-Attachment-Id: f_kmjk79i10

Ozs7IC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQ0KKHJlcXVpcmUgJ2VydCkNCg0KKGVydC1k
ZWZ0ZXN0IGJhdGNoLXByaW50ICgpDQogICJUZXN0IHRoYXQgd2hlbiBpbnZva2luZyBlbWFjcyBp
biBiYXRjaCBtb2RlIGFzIGENCnN1YnByb2Nlc3MgKGkuZS4gbm90IGRpcmVjdGx5IGZyb20gYSB0
ZXJtaW5hbCksIGxpbmVzIHByaW50ZWQNCndpdGggYHByaW5jJyBhcmUgZmx1c2hlZCB0byBvdXRw
dXQgaW1tZWRpYXRlbHkgKGkuZS4gbm90DQpidWZmZXJlZCkuIg0KICAobWVzc2FnZSAiOnN5c3Rl
bSAlcyA6dmVyc2lvbiAlcyIgc3lzdGVtLWNvbmZpZ3VyYXRpb24gZW1hY3MtdmVyc2lvbikNCg0K
ICAobGV0KiAoKHByb2MtYnVmIChnZXQtYnVmZmVyLWNyZWF0ZSAiaXNzdWUvYmF0Y2gtcHJpbnQi
KSkNCg0KCSA7OyBzdGFydCBhIG5ldyBlbWFjcyBwcm9jZXNzIHRoYXQgd2lsbCBwcmludCBhIGxp
bmUgdG8gc3Rkb3V0LA0KCSA7OyB3YWl0IGZvciBmaXZlIHNlY29uZCBhbmQgdGhlbiBleGl0Lg0K
CSAoY21kIChmb3JtYXQgIiVzIC1RIC0tYmF0Y2ggLS1ldmFsPVwiJXNcIiINCgkJICAgICAgKHN1
YnN0cmluZy1uby1wcm9wZXJ0aWVzIChjYXIgY29tbWFuZC1saW5lLWFyZ3MpKQ0KCQkgICAgICAn
KHByb2duIChwcmluYyBcXFwiaGlcXG5cXFwiKQ0KCQkJIChzaXQtZm9yIDUpKSkpDQoJIChwcm9j
IChzdGFydC1maWxlLXByb2Nlc3Mtc2hlbGwtY29tbWFuZA0KICAgICAgICAgICAgICAgICJ0ZXN0
L2JhdGNoLXByaW50IiBwcm9jLWJ1ZiBjbWQpKQ0KDQoJIChvdXRwdXRzICcoKSkpDQogICAgDQog
ICAgOzsgY2FwdHVyZSBlbWFjcyBvdXRwdXQNCiAgICAoc2V0LXByb2Nlc3MtZmlsdGVyIHByb2Mg
KGxhbWJkYSAocHJvYyBvdXRwdXQpDQoJCQkgICAgICAgKHB1c2ggb3V0cHV0IG91dHB1dHMpKSkN
CiAgICANCiAgICA7OyB3YWl0IGZvciB0aGUgcHJvY2VzcyB0byBzdGFydA0KICAgIChzbGVlcC1m
b3IgMikNCiAgICAoc2hvdWxkIChlcXVhbCAncnVuIChwcm9jZXNzLXN0YXR1cyBwcm9jKSkpDQog
ICAgOzsgcHJvZ3JhbSBzaG91bGQgaGF2ZSBwcmludGVkIG91dCAiaGlcbiINCiAgICAoc2hvdWxk
IChlcXVhbCAnKCJoaVxuIikgb3V0cHV0cykpDQoNCiAgICA7OyBraWxsIHByb2Nlc3MgYW5kIHdh
aXQgZm9yIGl0IHRvIGRpZQ0KICAgIChkZWxldGUtcHJvY2VzcyBwcm9jKQ0KICAgIChzbGVlcC1m
b3IgMSkpKQ0KDQo=
--000000000000f6b2e105be1130d3--




Acknowledgement sent to Ioannis Kappas <ioannis.kappas@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#47299; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 26 Jun 2022 18:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.