Re^2: IIS 6 and perl 5.8 pipes

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.

Comment on Re^2: IIS 6 and perl 5.8 pipes Select or Download Code

Replies are listed 'Best First'.
Re^3: IIS 6 and perl 5.8 pipes by tachyon (Chancellor) on Jun 21, 2004 at 02:20 UTC
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]
Re^3: IIS 6 and perl 5.8 pipes by graff (Chancellor) on Jun 21, 2004 at 02:35 UTC
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]