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

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Tue, 9 Feb 2021 20:15:34 +0000
> Cc: 46388@debbugs.gnu.org
> 
> Which appears to suggests that stderr always starts as "unbuffered"
> when a program starts, irrespective of how it was invoked?

AFAIR, on GNU/Linux stderr is not unbuffered by default.  We had a
long discussion of related issues in June 2019, I think people who
know about the glibc internals told there stderr is not really
completely unbuffered (and Posix allows that).

On MS-Windows it is by default unbuffered.

> Back to the windows behavior at hand, the simple test conducted with
> fwrite as the bug report mentioned, has a 2048 bytes associated with
> it which I will consider it to be categorized as "fully buffered",
> which brings it further away to the posix standard and even more further
> away from Linux being on the other end (always unbuffered).

I'm not sure your conclusion is correct.  I think the buffering is
imposed by the pipes which Emacs uses for communications with
subprocesses.  Or at least this is an additional buffering that is
related to the issue at hand.

> Unix convention is that stdin and stdout are line-buffered when
> associated with a terminal, and fully-buffered (aka block-buffered)
> otherwise. stderr is always unbuffered.
> 
> """
> 
> emphasis on *Unix convention ... stderr .. always unbuffered*, though
> it will be difficult to confirm this claim for all *nices)

I think Windows behaves the same, at least by default.  But GNU/Linux
isn't.

> For #2, emacs batch stderr behavior when invoked from outside the
> command line is not compatible with the posix standard, since it uses
> "fully buffered" mode, which actually makes it behave very differently
> from Linux (which is posix compliant by always having stderr as being
> unbuffered). Thus, the suggested patch actually addresses this
> concern, rather than invalidating it.

Again, are you sure it isn't the pipe that imposes buffering?

> (I understand ConPTY is the long term solution looking for a hacker,
> though I still do
> suppose the current behavior on windows is odd and needs to be
> addressed until that time).

I don't see it as odd.  The behavior of stdout and stdin could be odd
(again, due to pipes being used), but not that of stderr.