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#46388: 27.1; emacs -batch does not output messages immediately when invoked outside of the command prompt Date: Mon, 8 Feb 2021 21:42:09 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0000000000005c30c605bada0b06" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3054"; mail-complaints-to="usenet@ciao.gmane.io" To: 46388@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 09 00:55:41 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 1l9GNZ-0000j0-0c for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 00:55:41 +0100 Original-Received: from localhost ([::1]:38816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9GNY-0006D2-0s for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Feb 2021 18:55:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42180) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9EJC-0005kj-2y for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 16:43:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40518) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9EJB-0006WX-QT for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 16:43:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l9EJB-0007Hp-N5 for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 16:43:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Ioannis Kappas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Feb 2021 21:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46388 X-GNU-PR-Package: emacs Original-Received: via spool by 46388-submit@debbugs.gnu.org id=B46388.161282054827971 (code B ref 46388); Mon, 08 Feb 2021 21:43:01 +0000 Original-Received: (at 46388) by debbugs.gnu.org; 8 Feb 2021 21:42:28 +0000 Original-Received: from localhost ([127.0.0.1]:52064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9EIe-0007H3-CA for submit@debbugs.gnu.org; Mon, 08 Feb 2021 16:42:28 -0500 Original-Received: from mail-oo1-f48.google.com ([209.85.161.48]:39633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9EIb-0007Gq-Hn for 46388@debbugs.gnu.org; Mon, 08 Feb 2021 16:42:27 -0500 Original-Received: by mail-oo1-f48.google.com with SMTP id z36so3800938ooi.6 for <46388@debbugs.gnu.org>; Mon, 08 Feb 2021 13:42:25 -0800 (PST) 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=yHf2sAFP2LMWhXB8Ra91Ac4AHQI+YetmhHNFrZHr9SM=; b=hlMcI9ajTf58upgoS5DPfL8+QDN/eQdDGo1IEi/c0ANaZ0128dpBtkXCR8HCF1o3dX Z7epxF/O0jFrDhXE54R5MnxPCMbRNMxTIMbkOn5Rny0HJ7DRRTE9YV090TuZ6MJ9tOSo 13z6tephzPQm6QHg9ot+GbfYT4hHaBN3hsuVofDT4emyK5yaIS5t479eZRwnuXha8CZw LHgEs+B3DLGoX0jB9LdJ+ZLm1eSvT4CdIQmRZ7xxW+sUsJfwA67zPed93tjAwyK7rTYI fmRi+UyaouRqf2tyOmjKlsSU0tG0PfAn+LFJnuHP5jQXj9TuungwCoU/lEA0RctuyhI1 8q1w== 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=yHf2sAFP2LMWhXB8Ra91Ac4AHQI+YetmhHNFrZHr9SM=; b=EjV8p5R56TCUnAJ5XMQppfJsCrX3gNgSGA52Fk7+PEdRdeboxjLyMntjWPiTvf95+g BLJcvwdfADu6A/kR4xk1PnErzzIU2J5eWVSNNeI8zkoA0n9Y6up08Aoa+0zTO1yR4+rM YCdqbLjOZIxXzyWWj8jdKqkdV056YI3bKoPVEn94Ndj7cb3RVdmlJbvDUObM05WGw5AD 3osaQT3ZQukmIFGSXaVTHSrKddWCXpaOv30PxGE2EEabgX0HTJu3ZOSWk5U0vFTAt3q2 0/dwmGsEizFug8DVKaHa3NQlQe3k7G5chkSkBMMcNVP8DdnKJlyb6l9L0tkTx8b5CVIU rdOQ== X-Gm-Message-State: AOAM5314V813ibAZ2nqxr7q2M5ay4pd2Y0hGT6CjSgnlk9mevZsI3Njh yNm3920st8zOkiUabx49yJkg4OP02YJTQK1MJ+0dnagCe+z+0A== X-Google-Smtp-Source: ABdhPJwcsgORFcGnfFeXIrxZKN+PghuafeJlxdK1P2Gf+sHPRnau50nyAnjZnO7TaTlqbJVJ8cFSKHCJzDfzpAa8QV0= X-Received: by 2002:a4a:5787:: with SMTP id u129mr5281631ooa.81.1612820539761; Mon, 08 Feb 2021 13:42:19 -0800 (PST) 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:199642 Archived-At: --0000000000005c30c605bada0b06 Content-Type: text/plain; charset="UTF-8" Some analysis follows Looking at the code, it appears that /message/s in -batch mode are delivered to the process' standard error by the [editfnc.c:message()] ->[xdisp.c:message3_nolog()] ->[xdispl.c:message_to_stderr()] function, i.e. messages are written to stderr. The latter function uses the standard fwrite and fputc calls to deliver the message to stderr. The buffering regime used for stderror on windows appears to be different depending whether a program was started from the command prompt or not. When started from the command prompt stderr is unbuffered, while there is a buffer employed otherwise and output is only delivered when that buffer is full. Below is a sample C program that can demonstrate the behaviour, which writes a single character to the standard output and then exits after 2 seconds: #include #include #include int main() { fwrite("t", 1, sizeof("t"), stderr); sleep(2); return 0; } | case | invoked from | result | |------+------------------------+-------------------------------------------| | 1 | command prompt | prints "t", then after 2 seconds exits | | 2 | outside command prompt | after about 2 seconds prints "t", then exits | It appears that the buffer size used in #2 is 2048 bytes (i.e. the message is only immediately displayed when is more than 2048 bytes long). A solution thus to correct this behavior in emacs -batch on windows-nt would be to check if it is connected to the console, and when not, set stderr mode to unbuffered. A) Likely the win32 api provide GetConsoleMode() that can be used to check if a standard HANDLE is attached to the console. Given the STD_ERROR_HANDLE as an argument, it will return non-zero if is attached to the console or a 0 otherwise, setting GetLastError() to "The handle is invalid" message. B) To set stderr to an unbuffered mode, we can use standard C's setvbuf() with _IONBF (no buffering). C) The location where the descriptors are prepared for use in emacs appear to be at w32.c:init_ntproc(). If the above analysis is correct, here is an example patch that puts A/B/C together: --- a/src/w32.c +++ b/src/w32.c @@ -10216,6 +10216,19 @@ init_ntproc (int dumping) else _open ("nul", O_TEXT | O_NOINHERIT | O_WRONLY); _fdopen (2, "w"); + + /* When in -batch mode, windows appears to buffer stderr when it + is invoked outside of the command prompt. This has the + undesired side effect that /message/s are not output unless the + buffer is full or emacs exits */ + DWORD console_mode; + if (noninteractive && + // stderr is not attached to the console + !GetConsoleMode (GetStdHandle(STD_ERROR_HANDLE), &console_mode)) + { + // set stderr to unbuffered + setvbuf (stderr, NULL, _IONBF, 0); + } I have also attached an ert tests to capture the correct behavior. The test invokes an emacs -batch process which prints a /message/ and exits after five seconds. The test check immediately after two seconds if the batch process has output the message as expected. It can be invoked with: : emacs.exe -batch -l ert -l batch-message-test.el -f ert-run-tests-batch-and-exit --0000000000005c30c605bada0b06 Content-Type: application/octet-stream; name="batch-message-test.el" Content-Disposition: attachment; filename="batch-message-test.el" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kkx3l92a0 Ozs7IC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQ0KKHJlcXVpcmUgJ2VydCkNCg0KKGVydC1k ZWZ0ZXN0IGJhdGNoLW1lc3NhZ2UgKCkNCiAgIlRlc3QgdGhhdCB3aGVuIGludm9raW5nIGVtYWNz IGluIGJhdGNoIG1vZGUgYXMgYQ0Kc3VicHJvY2VzcyAoaS5lLiBub3QgZGlyZWN0bHkgZnJvbSBh IHRlcm1pbmFsKSwgL21lc3NhZ2UvcyBhcmUNCmZsdXNoZWQgdG8gb3V0cHV0IGltbWVkaWF0ZWx5 LiAiDQogIChtZXNzYWdlICI6c3lzdGVtICVzIDp2ZXJzaW9uICVzIiBzeXN0ZW0tY29uZmlndXJh dGlvbiBlbWFjcy12ZXJzaW9uKQ0KDQogICh3aXRoLXRlbXAtYnVmZmVyIA0KICAgIChsZXQqICgo cHJvYy1idWYgKGN1cnJlbnQtYnVmZmVyKSkNCg0KCSAgIDs7IHN0YXJ0IGEgbmV3IGVtYWNzIHBy b2Nlc3MgdGhhdCB3aWxsIHByaW50IGEgbWVzc2FnZSwNCgkgICA7OyB3YWl0IGZvciBmaXZlIHNl Y29uZCBhbmQgdGhlbiBleGl0Lg0KCSAgIChjbWQgKGZvcm1hdCAiZW1hY3MgLVEgLS1iYXRjaCAt LWV2YWw9XCIlc1wiIg0KCQkJJyhwcm9nbiAobWVzc2FnZSBcXFwiaGlcXFwiKSANCgkJCQkoc2l0 LWZvciA1KSkpKQ0KCSAgIChwcm9jIChzdGFydC1maWxlLXByb2Nlc3Mtc2hlbGwtY29tbWFuZA0K ICAgICAgICAgICAgICAgICAgInRlc3QvYmF0Y2gtbWVzc2FnZSIgcHJvYy1idWYgY21kKSkNCg0K CSAgIChvdXRwdXRzICcoKSkpDQogICAgICANCiAgICAgIDs7IGNhcHR1cmUgZW1hY3Mgb3V0cHV0 DQogICAgICAoc2V0LXByb2Nlc3MtZmlsdGVyIHByb2MgKGxhbWJkYSAocHJvYyBvdXRwdXQpDQoJ CQkJIChwdXNoIG91dHB1dCBvdXRwdXRzKSkpDQogICAgICANCiAgICAgIDs7IHdhaXQgZm9yIHRo ZSBwcm9jZXNzIHRvIHN0YXJ0DQogICAgICAoc2xlZXAtZm9yIDIpDQogICAgICAoc2hvdWxkIChl cXVhbCAncnVuIChwcm9jZXNzLXN0YXR1cyBwcm9jKSkpDQogICAgICA7OyBwcm9ncmFtIHNob3Vs ZCBoYXZlIHByaW50ZWQgb3V0ICJoaVxuIg0KICAgICAgKHNob3VsZCAoZXF1YWwgJygiaGlcbiIp IG91dHB1dHMpKQ0KDQogICAgICA7OyBraWxsIHByb2Nlc3MgYW5kIHdhaXQgZm9yIGl0IHRvIGRp ZQ0KICAgICAgKGRlbGV0ZS1wcm9jZXNzIHByb2MpDQogICAgICAoc2xlZXAtZm9yIDEpKSkpDQoN Cg== --0000000000005c30c605bada0b06--