Remember to include the list in your replies, so that everyone can help and be helped.
------------------------------------------------
On Fri, 7 Mar 2003 08:52:04 -0600, "Scot Robnett" <[EMAIL PROTECTED]> wrote:
> Thanks - but I don't understand how that redirect works. I've read about
> open, select, and filehandles and I still don't "get" the STDERR or STDOUT
> redirect.
Essentially the process being called needs to know how to handle this type of
interaction so using regular opens/filehandles is not likely to work. However, since
you are calling a process using backticks or you can use the IPC::Open3 mechanism then
either in the former case the process will be the shell, which does understand how to
do redirects, etc. or in the latter that is the very reason for Open3.
I don't see any examples of working code with the 2>&1
> functionality and I don't know in what context that gets used.
>
2>&1 are parameters that are parsed by the shell and instructs it how to handle the
outputs of the process it is about to run. Because backticks gets its information from
the shell, specifically STDOUT (of the shell) then if you tell the shell to redirect
the stderr of the process into the stdout (which is what 2>&1) does then the STDERR
will show up on the STDOUT channel, which will be caught by the backticks. The only
context where you need to watch out for this is when the process is *NOT* shelled out,
which I believe only occurs in the multiple argument version of 'system' (please list
correct me if I have this backwards).
> I am able to get the pid with IPC::Open2, but I want to display the results
> of the process, not the ID of the process.
>
Sorry I should have been more specific on this, I believe Open2 will not accomplish
what you need since it only works for STDOUT/STDIN. Open3 should be able to handle it
however as it handles STDIN/STDOUT/STDERR. You will *NOT* want to use the 2>&1
construct with an Open3!! Check the docs for info on getting the output, but
essentially you call Open3 on the command giving it filehandles where it should send
the output, then you should just read from those file handles like a normal 'open'd
file handle.
> Here's what it looks like using a standard filehandle, but the results
> aren't being saved into my variable and therefore not displaying in the
> browser. What should this code look like with the "missing link" added?
>
> #!/usr/bin/perl -w
>
> use strict;
> use CGI::Carp qw(fatalsToBrowser);
>
> my $cmd = `perl -c myscript.cgi`;
Change the above to:
my @output = `perl -c myscript.cgi 2>&1`;
Then you will want to test $? for the return code, on a failed return code (likely
anything but 0) then you will want to step through the @output array and print the
stderr. Check in:
perldoc perlop
Under the section "qx/STRING/" for examples and further description.
> open(STDERR,"<$cmd"); # No idea how to redirect 2>1 here
> while($line = <STDERR>) {
> print $line;
> }
> close(STDERR);
>
Here if my understanding is correct you are re-opening your own STDERR using the
command's STDOUT (which doesn't have anything on it). Then reading your own STDERR and
printing on own STDOUT. Which won't print anything because there is nothing on your
own STDERR because there is nothing on the processes STDOUT... but then you really
don't want to do things this way, at least outside of the context of an obfuscated
Perl contest :-).
HTH,
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
