DOS: Missing 1st SDTOUT record

[p5pRT]

Migrated from rt.perl.org#2975 (status was 'resolved')

Searchable as RT2975$

[p5pRT]

From wju@nac.net

To whom it may...

I sincerely apologize if this has been answered already (as I fell certain it must have been) but I have't found the answer yet.

I am a classroom instructor\, and I teach Perl quite often\, more and more in a Windows PC environment.

Attached are 2 documents (MSWord and plain text) which I distribute as part of my class intro. They describe what appears to be a DOS-related IO problem. I don't know if it's a Perl problem or an Windows OS problem\, but an answer would be greatly appreciated!

TIA\,

Walt

[p5pRT]

From wju@nac.net

DOS_Bug.doc

[p5pRT]

From wju@nac.net

A DOS problem​:

I'm not sure what causes this problem\, but it has never happened to me in a Unix environment. It happens most of the time in a DOS environment. Here's the problem​:

When a Perl program reads data from standard input and then writes something to standard output\, the first record written to standard output is "lost" if no IO redirection is used (I don't know what happens to it.)

Here's an example program called "IOBug.pl"​:

#This is the IOBug.pl program

while($rec=\) {   $array[$i++]=$rec; } foreach $rec (@​array) {   print($rec); }

When this program is run in a DOS window\, and the user types in some lines of input data\, the user must then close the standard input by typing a CONTROL-Z at the beginning of an input line. Here's a sample run (BOLD is what the user types)​:

C​:\perl IOBug.pl one two three four ^Z (you don't "see" this) two three four

C​:\

The program does print out all four lines of input\, but the user can only see the last three (the first line is lost.)

When this program is run with input redirection\, this problem does not happen. So if the file "input.txt" contains the same four input records as what the user had typed in\, when the program is run as such​:

C​:\perl IOBug.pl \< input.txt one two three four

C​:\

no output is lost.

When this program is run with output redirection\, this problem does not happen either. So when run as​:

C​:\perl IOBug.pl > output.txt one two three four ^Z(you don't "see" this)

C​:\

the file "output.txt" has all four input records.

As such\, I tend to think the problem lies somewhere within the terminal IO buffer management\, but I haven't been able to zero in on it. I've taught Perl in classrooms with mixed PC types running different versions of Windows 95 and 98 and yet machines which appear to be configured the same don't always behave the same.

Anyway\, the simple workaround is to just insert a statement which prints a new line immediately after the standard input is read (or at least before or as part of the very next print statement) so that if the problem occurs\, only the new line is lost.) Example​:

#This is the IOBug.pl program with the fix

while($rec=\) {   $array[$i++]=$rec; }

#The fix​: print("\n");

foreach $rec (@​array) {   print($rec); }

Walt Uotinen\, Top Shelf Technologies Page 2 of 2

[p5pRT]

From [Unknown Contact. See original ticket]

Walt Uotinen writes​:

C​:\perl IOBug.pl one two three four ^Z (you don't "see" this) two three four

C​:\

The program does print out all four lines of input\, but the user can only see the last three (the first line is lost.)

I think the first line is just "hidden behind" the ^Z indicator. Similar things happen on Unix​:

monk​:\~->perl -pwle 'BEGIN{undef $/}' a b aD b

I printed

a NL b NL ^D

and you see that the first line of output is put on the same line as "^D". It looks like the DOS shell does the same in a different order (so that ^Z overwrites 'one').

Ilya

[p5pRT]

From @iabyn

sounds like its not a bug.

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'