in reply to Re: Re: Re: win32/unix compatible script
in thread win32/unix compatible script

I still don't get it. With that fragment, my code can write to $out and it goes to the same place as STDOUT, right? 
use strict;
use warnings;
use FileHandle;

    my $in = new FileHandle "<&STDIN";
    my $out = new FileHandle ">&STDOUT";
    autoflush $out;

print $out "Hello World!\n";

[download]
This works just fine for me, in that the string appears on the console window just like it normally does.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: win32/unix compatible script
by dragonchild (Archbishop) on Jul 14, 2001 at 00:13 UTC
    That's exactly the point. Now, imagine this - you have a program that can be launched either from the commandline or set up as a telnet server. Doing this kind of binding, your code will always work the same, irregardless of whether or not you're a telnet server or commandline.
[reply]
      Could you explain it from the top? I'm hopelessly lost now. A program that uses stdin/out can be run via telnet, no big deal. What does using $out instead of STDOUT have to do with it?

      And I thought you said that this doesn't work on Windows. Doesn't work how?

      —John

[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]

In Section Seekers of Perl Wisdom