in reply to win32/unix compatible script

The second part of your question, regarding filenames - Perl "does the right thing". So, just use Unix-style filenames and you'll be just fine.

With regards to commandline options ... the thing I did when I had a Perl app that ran on both was to have a batchfile in Windows that had the commandline options I wanted and had it launch the Perl app. It was just simpler that way, plus it stayed within the GUI nature of Windows, to just double-click on some batchfile on the desktop.

Just as a warning, if you have an application that is a commandline app that binds STDIN and STDOUT to be descriptors, this will not work under windows. You will have to set up a telnet server, then telnet to yourself to get this descriptor behavior. There is a way to check which OS you're on (I don't remember which), then bring in the right modules to do the right thing.

Replies are listed 'Best First'.
Re: Re: win32/unix compatible script
by xphase_work (Pilgrim) on Jul 13, 2001 at 23:33 UTC
    You can find the OS you are on with these special vars: 
    $OSNAME

$^O     The name of the operating system under which this
        copy of Perl was built, as determined during the
        configuration process.  The value is identical to
        `$Config{'osname'}'.  See also the Config manpage
        and the -V command-line switch documented in the
        perlrun manpage.

    [download]
    From the perldoc perlvar POD.

    --xPhase

[reply]
[d/l]
Re: Re: win32/unix compatible script
by John M. Dlugosz (Monsignor) on Jul 13, 2001 at 23:43 UTC
    Just as a warning, if you have an application that is a commandline app that binds STDIN and STDOUT to be descriptors, this will not work under windows.
    What about STDIN/STDOUT doesn't work under Windows? Could you clarify?

    —John
    Win32 Programmer

[reply]
      What I'm talking about is the following code: 

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

      [download]

      What this allows you to do is to treat STDIN and STDOUT (keyboard and monitor, essentially) as if they were any old descriptor. Thus, you can have a commandline app that doesn't care if it's talking to a person at the keyboard or a telnet session.

      This works under Unix cause everything in Unix is treated (for all practical purposes) as if it's happening on a VT-100 terminal. Each window is treated by the kernel as its own process with its own input and output. The input and output (generally) is the same for all your windows, but the kernel doesn't make that optimization.

      Windows does, which means that STDIN isn't an attribute of a given window, but of the OS as a whole. Thus, the problem.

      It's easy to get around - you just have to telnet to yourself. :)

[reply]
[d/l]
        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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom