| [reply] |
Ok. I think we've got a few misconceptions here.
Firstly, I'm not talking about logging into a computer via telnet, then running it. I'm talking about a program that acts as a telnet server as well as a console program.
Given that, the program doesn't know whether it is talking to a monitor or a telnet socket. So, it cannot have a line similar to "print STDOUT" or just "print". It has to talk completely in terms of descriptors, like $out.
Now, the way (on Unix) to do this is to bind STDIN and STDOUT so that you can address them as filehandles.
Tangent: a filehandle is really a descriptor. You're sending information to some place. From a syntatical point of view, it doesn't matter whether or not that place is a file, a monitor, or some IP connection to another machine. The OS is what routes the data to the file, monitor, or IP connection.
So, you are now able to (on Unix) address STDIN/STDOUT as descriptors.
The problem with Windows is that you cannot bind STDIN/STDOUT as descriptors. So, the way around is to telnet to yourself, and treat those as descriptors. The information simply routes right back to yourself. :)
| [reply] |
From a syntatical point of view, it doesn't matter whether or not that place is a file, a monitor, or some IP connection to another machine. The OS is what routes the data to the file, monitor, or IP connection. ... The problem with Windows is that you cannot bind STDIN/STDOUT as descriptors.
Under win32, the standard input, output, and error are file handles just like any others. The underlying OS primitive WriteFile is given a file handle and a buffer to write. If they couldn't be treated in a uniform manner, redirection on the command line wouldn't work, would it?
I think I see what you're getting at. The program can run as a normal command-line, writing to stdout. Or, you can invoke it with some flag and it listens to a socket and accepts a connection, and then uses that socket instead of stdout.
So, the program is written to use $out for all its writes. Why doesn't that work for you? It works fine for me. I've written code that takes a file descriptor as a parameter, and it has no problems with passing \*STDOUT.
Other than being predefined, STDIN and STDOUT behave just like any other file descriptor in Perl. You could re-point STDOUT to the socket handle, for example, instead of using $out in all your print statements. (or you could use select to make $out the default).
—John
| [reply] |