GNU bug report logs - #46388
27.1; emacs -batch does not output messages immediately when invoked outside of the command prompt

Previous Next

Package: emacs;

Reported by: Ioannis Kappas <ioannis.kappas <at> gmail.com>

Date: Mon, 8 Feb 2021 21:22:02 UTC

Severity: normal

Found in version 27.1

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46388 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#46388: 27.1; emacs -batch does not output messages immediately when invoked outside of the command prompt
Date: Thu, 11 Feb 2021 19:25:31 +0000

> On 11 Feb 2021, at 14:09, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
>> Date: Thu, 11 Feb 2021 08:10:34 +0000
>> Cc: 46388 <at> debbugs.gnu.org
>> 
>>> My reading of the code is that we already fflush stderr after emitting
>>> a message, so this should already happen.  See message_to_stderr.  If
>>> that still doesn't help, then there's some buffering in the OS (for
>>> example, in the pipe machinery itself), which we cannot control.
>> 
>> the xdisp.c:message_to_stderr() is the first function i studied with
>> gdb when I started the investigation. Unless I've missed something,
>> it does not seem to lead to calling fflush (under windows at least):
> 
> Then maybe this:
> 
>> /* Return the error output stream.  */
>> static FILE *
>> errstream (void)
>> {
>>  FILE *err = buferr;
>>  if (!err)
>>    return stderr;
>>  fflush_unlocked (stderr);  <<<<<<<<<<<<<<<<
>>  return err;
>> }
> 
> should be fixed to fflush 'buferr' instead (or in addition to stderr)?
> 
> Paul, isn't that a bug that we fflush stderr here, and not 'buferr’?

(just a small note, “buffer" is NULL under windows, the fn thus returns without flushing anything. Even if buffer was not NULL, the fflush fn would have flushed the content of what ever has been accumulated on the stderr buffer so far, but not the message just  sent to message_to_stderr that we want to print out. Although, there would be this weird effect; message_to_sderr()  does an fwrite of the message followed by an fputc of a newline. This means that if errstream() was to fflush stderr, it would have flushed only the message written by fwrite, and not the newline written by fputc. I think that, if we are indeed considering to explicitly flush the message to stder, the correct place to do it would be directly inside the message_to_stderr(), thanks)







This bug report was last modified 4 years and 70 days ago.

Previous Next


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