Mail Archives: djgpp/2000/11/01/10:26:49
On Wed, Nov 01, 2000 at 02:30:24PM +0200, eliz AT is DOT elta DOT co DOT il wrote:
> This was submitted as a bug report to the DJGPP bug-tracking facility
> (http://www.delorie.com/djgpp/bugs/).
>
> Please note that controversial reports such as this one, where it's not
> clear whether the bug is in DJGPP or in the target platform, should be
> posted to the DJGPP forum (comp.os.msdos.djgpp) instead of being filed
> with the above site, because most of the time these are not DJGPP bugs.
>
> > running on Windows NT 4.0 SP6
> >
> > This is my test prog (check.c)
> >
> > #include <stdio.h>
> > #define LT "\n\r"
> > int main () {
> > printf("Line 5" LT);
> > printf("Line 4" LT);
> > printf("Line 3" LT);
> > printf("Line 2" LT);
> > printf("Line 1" LT);
> > fflush(stdout);
> > return 0;
> > }
> >
> > In a DOS box I enter
> > gcc check.c -o check
> >
> > (With d:\djgpp\bin at the head of the path)
> >
> > I get two files 'check' and 'check.exe' produced. If I now type 'check', I
> > get a blank line but no other output. The same thing happens if LT is
> > changed to either "\n" or "\r\n" as well.
>
> I cannot reproduce this on NT 4 SP4 and SP5: the program runs as expected,
> producing the 5 lines above. I don't have access to SP6, though. Can
> someone who has access to SP6 test this and report the results?
>
> My guess would be that this is due to some setup specific to your system
> (is it possible that 'check' is a name of some command on that machine?).
I've found that if I enter
check > check.out
type check.out
I get the expected file contents. It seems to be a problem which is
specific to file I/O direct to a DOS box.
If the output is fprintf'd to stderr, again nothing appears on the
screen. If I redirect 2> to a file, the file contains valid output.
Thus, character versus line buffering on output to the DOS box doesn't
seem to be relevant.
For what I want, redirecting to a file and typing that after is a
reasonable work-around, but it would still be nice if direct I/O worked.
However, it's starting to look like it may just be the setup of this PC
rather than a general NT DOS box problem, in which case please cancel
the bug report as a non-problem if no-one else can reproduce it.
- Raw text -