Wow! Quite a detailed response...thank you.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 9:25 AM To: Scot Robnett Cc: [EMAIL PROTECTED] Subject: RE: Getting a STDOUT value 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]
