From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ioannis Kappas Newsgroups: gmane.emacs.bugs Subject: bug#47299: 27.1; emacs --batch on MS-Windows does not immediately display `print'ed lines when invoked outside of the Command Prompt Date: Sun, 21 Mar 2021 19:45:19 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000f6b2e105be1130d3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38048"; mail-complaints-to="usenet@ciao.gmane.io" To: 47299@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 21 20:46:49 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lO42D-0009mh-BF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 20:46:49 +0100 Original-Received: from localhost ([::1]:60854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO42C-0007uk-Ci for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 15:46:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO41S-0007td-Tm for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 15:46:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43973) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lO41S-0001yh-MF for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 15:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lO41S-0008BZ-Ko for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 15:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ioannis Kappas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Mar 2021 19:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 47299 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.161635594231431 (code B ref -1); Sun, 21 Mar 2021 19:46:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 21 Mar 2021 19:45:42 +0000 Original-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 Original-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 Original-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 Original-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 Original-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) 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:202804 Archived-At: --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--