From unknown Thu Aug 14 21:49:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#47299 <47299@debbugs.gnu.org> To: bug#47299 <47299@debbugs.gnu.org> Subject: Status: 27.1; emacs --batch on MS-Windows does not immediately display `print'ed lines when invoked outside of the Command Prompt Reply-To: bug#47299 <47299@debbugs.gnu.org> Date: Fri, 15 Aug 2025 04:49:20 +0000 retitle 47299 27.1; emacs --batch on MS-Windows does not immediately displa= y `print'ed lines when invoked outside of the Command Prompt reassign 47299 emacs submitter 47299 Ioannis Kappas severity 47299 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 21 15:45:42 2021 Received: (at submit) by debbugs.gnu.org; 21 Mar 2021 19:45:42 +0000 Received: from localhost ([127.0.0.1]:55519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO414-0008Aq-4t for submit@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 ) id 1lO40y-0008Ae-Kp for submit@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 ) id 1lO40y-0007Zm-BK for bug-gnu-emacs@gnu.org; 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 ) id 1lO40w-0001l3-Gg for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 15:45:32 -0400 Received: by mail-ot1-x32a.google.com with SMTP id w21-20020a9d63950000b02901ce7b8c45b4so13880899otk.5 for ; 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 Date: Sun, 21 Mar 2021 19:45:19 +0000 Message-ID: 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@gnu.org Content-Type: multipart/mixed; boundary="000000000000f6b2e105be1130d3" Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=ioannis.kappas@gmail.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
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&= #39; and its variants (e.g. `prin1' and `princ'), output the printe= d=C2=A0
representation of an OBJECT pas= sed in as an argument.

A user expects to see `print'ed output fr= om 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 expe= rience.

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

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

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

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

| `system-type' = | invoked-from =C2=A0 | result =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|----= -----------+----------------+-----------------|
| 'windows-nt =C2=A0= | Command Prompt | immediately =C2=A0 =C2=A0 |
| 'windows-nt =C2=A0= | M-x shell =C2=A0 =C2=A0 =C2=A0| after 5 seconds |
| 'gnu/linux = =C2=A0 =C2=A0| terminal =C2=A0 =C2=A0 =C2=A0 | immediately =C2=A0 =C2=A0 |<= br>| 'gnu/linux =C2=A0 =C2=A0| M-x shell =C2=A0 =C2=A0 =C2=A0| immediat= ely =C2=A0 =C2=A0 |

Further more, the behavior is even worse when em= acs --batch is invoked
programmatically=C2=A0by Emacs itself. If the acc= umulated `print'ed output
length is relatively small (less than 4096= bytes), no output is
received by the parent Emacs process, unlikely tha= t on 'gnu/linux
where output is received while lines are `print'= ed out.

The attached `ert' test demonstrates the above point usi= ng `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

| `syst= em-type' | result =C2=A0 =C2=A0 =C2=A0|
|---------------+-----------= --|
| 'windows-nt =C2=A0 | fail =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| &#= 39;gnu/linux =C2=A0 =C2=A0| pass =C2=A0 =C2=A0 =C2=A0 =C2=A0|

Analys= is with likely fixes to follow.

(This report is similar to bug#46388= )

Configured using:
=C2=A0'configure --prefix=3D/mingw64 --b= uild=3Dx86_64-w64-mingw32 --with-modules
=C2=A0--without-dbus --without-= compress-install 'CFLAGS=3D-march=3Dx86-64
=C2=A0-mtune=3Dgeneric -O= 2 -pipe' CPPFLAGS=3D-D__USE_MINGW_ANSI_STDIO=3D1
=C2=A0'LDFLAGS= =3D-pipe
=C2=A0-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-= image-base-high''
--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: 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-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 21 17:06:47 2021 Received: (at 47299) by debbugs.gnu.org; 21 Mar 2021 21:06:47 +0000 Received: from localhost ([127.0.0.1]:55552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO5Ha-0001eC-JC for submit@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 ) id 1lO5HX-0001dy-4q for 47299@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@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 Date: Sun, 21 Mar 2021 21:06:28 +0000 Message-ID: Subject: 27.1; emacs --batch on MS-Windows does not immediately display `print'ed lines when invoked outside of the Command Prompt To: 47299@debbugs.gnu.org Content-Type: multipart/alternative; boundary="00000000000026385905be12536c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47299 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
Analysis fo= llows.

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
immediat= ely when invoked outside of the command prompt) the issue
= stems from the expectation that stdout buffering s= hould behave like in
POSIX system= s, which is not necessarily the case on 'windows-nt.
<= font face=3D"monospace">
The = POSIX standard reads
under "stderr, stdin, stdout - s= tandard I/O streams":

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

s= tdout 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 E= macs M-x=C2=A0shell. I conside= r=C2=A0
this line-bu= ffered behavior of 'gnu/linux to fall under the=C2=A0"interactive=C2=A0
device" of=C2=A0the standard mentioned above.

(When std= out 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 @
written to investigate the = buffering behavior of stderr on MS-Windows,
i.e. unbuffered when attached to console, fully buffered<= /div>
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 &#= 39;gnu/linux.

As such, two likely fixes are presented below, = one that flushes stdout
on a newl= ine only iff stdout is attached to a pipe (as if it is the
"interactive device" of the POSIX stand= ard) but staying fully buffered
o= therwise (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 f= or redirections to files).

(Please note that the intention be= low is to change
src/print.c:prin= tchar_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=C2=A0 =C2=A0 |=C2=A0 2 ++
src/sysdep.c=C2=A0 =C2=A0| 21 +++++++++++++++++++++
src/sysstdio.h |=C2=A0 1 +
src/w32.c=C2=A0 =C2=A0 =C2=A0 | 13 +++++++++++++
src/w32.h=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = 3 +++

modified=C2=A0 =C2=A0src/print.c
@@ -234,6 +234,8 @@ printchar_to_stream (unsigned int c= h, FILE *stream)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0if (ASCII_CHAR_P (ch))
=C2=A0 {
=C2=A0 =C2=A0 putc= (ch, stream);

<= div>+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ch =3D= =3D '\n')
+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 maybe_flush_stdout();
=C2=A0#ifdef WINDOWSNT
=C2=A0 =C2=A0 /* Send the out= put to a debugger (nothing happens if there
=C2=A0 =C2=A0 =C2=A0 =C2= =A0isn't one).=C2=A0 */
modif= ied=C2=A0 =C2=A0src/sysdep.c
@@ -= 2821,6 +2821,27 @@ errwrite (void const *buf, ptrdiff_t nbuf)
<= div>=C2=A0 =C2=A0fwrite_unlocked (buf, 1, nbuf, er= rstream ());
=C2=A0}
=
=C2=A0
+/* On windows, stdout is unbuffered when attached to the console but
+=C2=A0 =C2=A0fully buffered (4096= bytes) when redirected to a pipe (this buffer
+=C2=A0 =C2=A0is complementary to the pipe buffer).
+
+=C2=A0 =C2=A0Since Emacs --batch, at least on Windows, does not flush s= tdout it
+=C2=A0 =C2=A0means prin= ting to standard output (for example with `princ' and its
<= div>+=C2=A0 =C2=A0variants) will not reach the par= ent process until at least this
+= =C2=A0 =C2=A0process exits or the stream buffer is full, resulting to a ver= y
+=C2=A0 =C2=A0poor interaction = with the parent, contrary to how 'gnu/linux stdout works.
<= div>+
+= =C2=A0 =C2=A0We thus provide an interface to these functions to flush stdou= t
+=C2=A0 =C2=A0when has been red= irected to a pipe.
+*/
+void maybe_flush_stdout (void)
+{
+#ifdef WINDOWSNT
+=C2=A0 if (is= _stdout_pipe())
+=C2=A0 =C2=A0 ff= lush_unlocked(stdout);
+#endif /*= WINDOWSNT */
+}
+
=C2= =A0/* Close standard output and standard error, reporting any write<= /div>
=C2=A0 =C2=A0 errors as best we can.=C2= =A0 This is intended for use with atexit.=C2=A0 */
=C2=A0void
modi= fied=C2=A0 =C2=A0src/sysstdio.h
@= @ -27,6 +27,7 @@ #define EMACS_SYSSTDIO_H
=C2=A0#include "unlocked-io.h"
=C2=A0
=C2=A0ext= ern FILE *emacs_fopen (char const *, char const *);
+extern void maybe_flush_stdout (void);
=C2=A0extern void errputc (int);
=C2=A0extern void errwrite (void const *, ptrdiff= _t);
=C2=A0extern void close_outp= ut_streams (void);
modified=C2=A0= =C2=A0src/w32.c
@@ -10190,6 +101= 90,12 @@ term_ntproc (int ignored)
=C2=A0 =C2=A0term_w32select ();
=C2=A0}
=C2=A0
= +static bool _is_stdout_pipe =3D false;
+bool is_stdout_pipe (void)
+{
+= =C2=A0 return _is_stdout_pipe;
+}=
+
=C2=A0void
=C2=A0init= _ntproc (int dumping)
=C2=A0{
@@ -10268,6 +10274,13 @@ init_ntproc= (int dumping)
=C2=A0 =C2=A0 =C2= =A0_fdopen (2, "w");
= =C2=A0 =C2=A0}
=C2=A0
+=C2=A0 HANDLE soh =3D (HANDLE)_get_osfhandl= e(_fileno(stdout));
+=C2=A0 _is_s= tdout_pipe =3D
+=C2=A0 =C2=A0 /* = is pipe (anonymous, named or socket)*/
+=C2=A0 =C2=A0 GetFileType(soh) =3D=3D FILE_TYPE_PIPE
+=C2=A0 =C2=A0 /* and is definitely not a socket= */
+=C2=A0 =C2=A0 && Get= NamedPipeInfo(soh, NULL, NULL, NULL, NULL);
+
=C2=A0 =C2=A0/* unfo= rtunately, atexit depends on implementation of malloc */
<= font face=3D"monospace">=C2=A0 =C2=A0/* atexit (term_ntproc); */
=C2=A0 =C2=A0if (!dumping)
modified=C2=A0 =C2=A0src/w32.h
<= 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
=C2=A0extern HANDLE maybe_load_unicows_dll (void);
=
=C2=A0extern void globals_of_w32 (void);
=C2=A0
+/* return whether standard output is redirected to a pipe. */<= /font>
+extern bool is_stdout_pipe (void= );
+
=C2=A0extern void term_timers (void);
=C2=A0extern void init_timers (void);
= #+end_src

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

=C2=A0 modified=C2=A0 =C2=A0src/print.c
=C2=A0 @@ -235,6 +235,14 @@ printchar_to_stream (unsigned = int ch, FILE *stream)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 putc (ch, stream);
=C2=A0 =C2=A0#ifdef WINDOWSNT
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Flush stdo= ut after outputting a newline since stdout is
=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
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PO= SIX when attached to an "interactive device" (see
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"stderr, stdin, stdout - standard I/O streams" in IEEE<= /font>
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01003.1-2017) */
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ch =3D=3D '\n'= ; && stream =3D=3D stdout)
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fflush_unlocked(stdout)= ;
=C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Send the o= utput to a debugger (nothing happens if there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn&#= 39;t one).=C2=A0 */
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (print_output_debug_flag && stream = =3D=3D stderr)

<= div>#+end_src

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

Thanks=

--00000000000026385905be12536c-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 23 07:33:41 2021 Received: (at 47299) by debbugs.gnu.org; 23 Mar 2021 11:33:41 +0000 Received: from localhost ([127.0.0.1]:59717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOfI4-0001xL-WE for submit@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 ) id 1lOfI1-0001x6-8Z for 47299@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Ioannis Kappas In-Reply-To: (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: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47299 Cc: 47299@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Ioannis Kappas > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 23 15:06:16 2021 Received: (at 47299) by debbugs.gnu.org; 23 Mar 2021 19:06:16 +0000 Received: from localhost ([127.0.0.1]:33011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOmM4-0007A2-Kk for submit@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 ) id 1lOmM1-00079l-Or for 47299@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@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: <837dly85pq.fsf@gnu.org> In-Reply-To: <837dly85pq.fsf@gnu.org> From: Ioannis Kappas Date: Tue, 23 Mar 2021 19:05:57 +0000 Message-ID: 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47299 Cc: 47299@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, On Tue, Mar 23, 2021 at 11:33 AM Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 26 14:24:16 2022 Received: (at 47299) by debbugs.gnu.org; 26 Jun 2022 18:24:16 +0000 Received: from localhost ([127.0.0.1]:48973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5Wvg-0001aD-HX for submit@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 ) id 1o5Wvc-0001Zu-Mz for 47299@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 ) id 1o5WvS-0004pT-Nv; Sun, 26 Jun 2022 20:24:05 +0200 From: Lars Ingebrigtsen To: Ioannis Kappas 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: <837dly85pq.fsf@gnu.org> Date: Sun, 26 Jun 2022 20:24:02 +0200 In-Reply-To: (Ioannis Kappas's message of "Tue, 23 Mar 2021 19:05:57 +0000") Message-ID: <87czevb7wd.fsf@gnus.org> 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 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 , 47299@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ioannis Kappas 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 26 14:24:20 2022 Received: (at control) by debbugs.gnu.org; 26 Jun 2022 18:24:20 +0000 Received: from localhost ([127.0.0.1]:48976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5Wvj-0001aS-OB for submit@debbugs.gnu.org; Sun, 26 Jun 2022 14:24:20 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5Wvh-0001a1-EL for control@debbugs.gnu.org; Sun, 26 Jun 2022 14:24:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=M2wVD2qxYRtc5Mm+DLDwuq0lIgkTMCeZiAUVnxw/hvA=; b=U5eywQldbsCxxDyW8PgfqXrwBg KOBc7rXBEZOt/KCgEhf3oT+NwgqeUABpKZZgcLVabFCU+JSAqiHicAYdmgP+/rla3O+Wr4skaywCv ooAFJo8rOcAx7zUYALisZ+zwiO+TzzXNiEFq+TTvgAJrClrJJtA5O4mOQWlVmh4fATrQ=; 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 ) id 1o5WvZ-0004pa-IZ for control@debbugs.gnu.org; Sun, 26 Jun 2022 20:24:11 +0200 Date: Sun, 26 Jun 2022 20:24:09 +0200 Message-Id: <87bkufb7w6.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #47299 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: close 47299 29.1 quit 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: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 47299 29.1 quit From unknown Thu Aug 14 21:49:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 25 Jul 2022 11:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator