Recently, whilst trying to save a program I had written as con.pl under Win XP, I got an error message telling me that con was a "reserved device name". I added a v, saving the program as "conv.pl".

Running the program later at the command line, I mistakenly typed "perl con.pl" instead of "perl conv.pl". To my surprise the perl interpreter did not stop in its tracks with a "No such file or directory" error. Instead it presented me with a prompt, as if I had given it a filename of "-" (which will cause the interpreter to read program code from STDIN, and execute it after you have entered EOF, usually ^D).

I keyed in print 'Hi', entered ^D, and pressed <ENTER>. The interpreter ran the print command, then exited without event. After some thought, I reasoned that it was behaving in this way because I had given it the Windows device "con", and it had treated it as any other filehandle. It seems windows will treat con.* as con. I tested this by running "perl con.bat" , "perl con.exe", and even "perl con.perlmonks". They all worked out as before, reading from STDIN, and executing it.

I then used the nul device, which is similar to Unix's /dev/null. The interpreter exited without a word, as I had expected, since the nul device leads nowhere.

I then took the next logical step, opening both the con and nul devices as filehandles in a test program I created.

#!perl
use strict;
use warnings;

open(IN,"con") || die $!;
print "Enter a line:";
my $line=<IN>;
print "Right back at ya: $line";

open(OUT,">nul") || die $!;
print OUT "Garbage Out";
[download]

And it worked. It read from the keyboard in line 7, and wrote to the nul device in line 11.

I am not really sure what use this could have but I posted it here mainly as further proof of perl's TMTOWTDI nature.

And of course, to win a wager or two with( you know, "I bet ya I can read from the keyboard without using the STDIN filehandle").

update (broquaint): title changed (was Reading from STDIN...without using STDIN)