On 25 November 2015, Gary Johnson <[email protected]> wrote:
> On 2015-11-25, B. Wilson wrote:
> > When running :make and there is output to both stderr and stdout,
> > I'm seeing a degree of reordering in the displayed output.
> >
> > I didn't notice any similar issues when searching the mailing
> > list, but forgive me if this is already a known bug/feature.
> >
> > Below I give steps on how to reproduce the behaviour on my machine
> > as well as the output of `vim --version`. I will be happy to
> > produce any other details that may be necessary.
> >
> >
> > ## Reproducing the Behaviour
> >
> > Create the following `foo.c` file:
> >
> > #include <stdio.h>
> >
> > int main()
> > {
> > printf("This is a message on stdout and should appear
> > first\n");
> > fprintf(stderr, "This is a message on stderr and should
> > appear second\n");
> >
> > return 0;
> > }
> >
> > Create the following `Makefile`:
> >
> > run: foo
> > @./foo
> >
> > Compile the program:
> >
> > $ make foo
> >
> > Let make compile and run the program:
> >
> > $ make run
> > cc foo.c -o foo
> > This is a message on stdout and should appear first
> > This is a message on stderr and should appear second
>
> In this case, foo's stdout and stderr are directed to your terminal,
> so those outputs are unbuffered.
Actually stdout is line-buffered, and stderr is unbuffered. The
newline on stdout triggers a flush.
> > Now compare this to when calling `:make run` from `vim`:
> >
> > :make run
> > This is a message on stderr and should appear second
> > This is a message on stdout and should appear first
> >
> > Press ENTER or type command to continue
>
> In this case, foo's stdout and stderr are directed to Vim's pipeline
> that collects make's output, so those outputs are buffered.
Actually stderr continues to be unbuffered, but now stdout is
block-buffered. The newline on stdout no longer triggers a flush.
> Consequently, the lines appear in the order in which the buffers are
> flushed and not necessarily the order in which the lines were written
> to the buffers.
>
> The decision to buffer or unbuffer streams is made by the shell, not
> by Vim.
True, but not really relevant. The lines are already swapped when
they reach the shell.
On 25 November 2015, Tony Mechelynck <[email protected]>
wrote:
> If the program had been written in Python (like Mercurial is), setting
> $PYTHONUNBUFFERED to some nonempty string would have prevented
> buffering. With C and bash, I don't know.
You can make stdout unbuffered:
#include <stdio.h>
int main()
{
setbuf(stdout, NULL);
printf("This is a message on stdout and should appear first\n");
fprintf(stderr, "This is a message on stderr and should appear
second\n");
return 0;
}
or you can flush stdout before writing to stderr:
#include <stdio.h>
int main()
{
printf("This is a message on stdout and should appear first\n");
fflusf(stdout);
fprintf(stderr, "This is a message on stderr and should appear
second\n");
return 0;
}
But you can only do this because you can recompile the program. If
you can't change the program you're out of luck. You can't fix the
problem without changing the program itself.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
