aquarium has asked for the wisdom of the Perl Monks concerning the following question:

It seems that I can write to files etc., but any command that uses a pipe just returns undef, (contrived example) 
$retval = `help | more`;
#this will not work
$retval = `help`;
#that will work

[download]
It works on IIS 5 though. Have been searching high and low, and only found one reference from someone which states that IIS 6 does not provide STDIN/STDOUT/STDERR, so pipes don't work. Is this true? I'm writing a script at work that requires a backticks construct with a pipe...how to make it work on IIS 6?

Replies are listed 'Best First'.
Re: IIS 6 and perl 5.8 pipes
by BUU (Prior) on Jun 20, 2004 at 12:48 UTC
    No idea about IIS and pipes, but perhaps you could try: 
    open MORE,"|more" or die "wtf hax:$!";
open HELP,"help|" or die"more hax:$!";
print MORE <HELP>;

    [download]
    Of course, you can't read and print to more without getting slightly more complicated, namely IPC::Open2
    use IPC::Open2;
open HELP,"help|" or die"more hax:$!";
open2(MORE_READ,MORE_WRITE,'more');
print MORE_WRITE <HELP>;
close MORE_WRITE; #send eof so the program will give us stdout
print <MORE_READ>;

    [download]
    And of course, all the usual fun of deadlocks and such can apply, but if you're just doing basic shell linear direction it shouldn't be a problem.
[reply]
[d/l]
[select]
[reply]
Re: IIS 6 and perl 5.8 pipes
by NetWallah (Canon) on Jun 20, 2004 at 21:38 UTC
    I doubt very much that IIS 6 (or any other version) has anything to do with this issue.

    Pipes work fine - Most likely, you are missing some PATH information, while running under IIS.

    I Suggest that you add "2>&1" to the end of your executed string, so that you can get STDERR - the output would probably point the way.

    Offense, like beauty, is in the eye of the beholder, and a fantasy.
    By guaranteeing freedom of expression, the First Amendment also guarantees offense.

[reply]
Re: IIS 6 and perl 5.8 pipes
by ambrus (Abbot) on Jun 20, 2004 at 22:01 UTC

    In general, pipes should just work with backticks. However, I don't understand what you want to do by `help | more`. More is a pager, that prints its input page by page, waiting for a keypress after each page. It makes no sense to capture the output of more with backticks. Maybe you want system instead?

[reply]
[d/l]
[select]
      ok...the example was only contrived...as the actual utilities involved are developed by our company. the utilities are NOT the culprit. Most of our database based utilities will print all rows of a table if run without passing (via STDIN) a value to limit selection. So for (real) example 
      $retval=`seluser`;

      [download]
      runs in a cgi via IIS no problems...retrieving all user id's into the scalar. However: 
      $retval=`echo 123 | seluser`;

      [download]
      will work from command line (or even with apache), returning user id for that user only. It works on IIS 5, but not with IIS 6. I've been playing around with all our and MS utilities to see what's the deal....and have come up with the most likely scenario being that pipes don't work from a script in IIS 6. Sorry about the contrived example before with `help | more` as i am trying to make sure i don't violate company law.
[reply]
[d/l]
[select]

        Windows has a somewhat broken take on STDIN, STDERR and STDOUT. Just as a random thought I wonder what the result of this might be: 

        $retval = `echo 123 | more`;
print while <STDIN>;

        [download]

        Just wondering if Win32/IIS/Perl is confusing the shell and the IIS script stdin/stdout when you start using pipes.

        cheers

        tachyon

[reply]
[d/l]
        The problem may be in the shell that is being used by IIS to run the process -- I'm only guessing here, since I have no contact with any version IIS. If one of the differences between IIS 5 and IIS 6 is the nature of the shell used to run sub-processes, it's conceivable (though stupid) that they would choose to disable pipeline commands.

        If you're using sub-shells to run utilities that talk to a general-purpose database (like oracle or some other ODBC-capable server), you might consider using the DBI module and connecting your script directly to the database. It would mean replicating in your perl script the queries that are implemented by the current command line utilities, but this might enable a lot of possibilities...

[reply]

Back to Seekers of Perl Wisdom