Mail Archives: djgpp/2001/05/17/11:00:22
Eli Zaretskii wrote:
> On Wed, 16 May 2001, Michiel de Bondt wrote:
>
> > Hans-Bernhard Broeker wrote:
> >
> > > There is none --- cprintf() isn't buffered, so it doesn't need any
> > > fflush workalike, to begin with. Instead, you'ld have to be sure you
> > > fflush(stdout) before any cprintf() or gotoxy() call following a
> > > printf().
> >
> > This does not agree with observation. Probably, Windows 95 should be
> > blamed.
>
> Please describe what do you see that contradicts what Hans-Bernhard
> wrote. AFAIK, Windows 9X does not change the effect of cprintf in any
> way.
>
Strange. What I do is removing the bar of progress asterisks by cprintf ("\b
\b")'s
Then, I do printf("Some message.\n ").
What I see: First, half of the asterisks is removed. Then, the message is
printed.
After that, the other half of the asterisks is removed. At last, the cursor
is moved
to after the message. The cprintf ("\b \b")'s might be done in a procedure
called by
an alarm event. Before printing the message, I use alarm (0) to cancel the
alarm
event, and then, call the alarm event procedure myself to remove the
asterisks.
The alarm event procedure remembers the number of asterisks and adjusts it
to the new number of asterisks, so it can be called twice to remove the
asterisks
without any problem.
So it seems that printf gets an old cursor position.
>
> > I wish to print all information to stdout, except the progress asterisks
> > "*" and search paths, and the "\b \b" to remove them.
>
> And what do you want to do with progress indicator and search path? IN
> particular, what do you want to do with them if stdout is redirected?
>
I wish them to be printed to the screen. Especially search paths change every
second. They must not be printed to a file. They can be printed to the
screen,
since cprintfing "\b \b"'s removes them from the screen, but not from a file.
>
> > The program dvips distinguishes console output and
> > standard output as well, i.e. it seems so at least. How can that be?
>
> Perhaps because it prints part of the text to stderr and the rest to
> stdout.
But can stderr and stdout not conflict since they are both the screen? Maybe,
it
is a good idea to write to stderr instead of the console.
Best regards, Michiel
- Raw text -