in reply to Re: Re: Re: Re: Re: Re: Re: help with arrays
in thread help with arrays

$retval when printed outputs "256". Or at least it used to. Now all I get in the browser is "INTERNAL SERVER ERROR" and the error_log has the same error listed that I posted previously.

Prince99

Too Much is never enough...

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Re: help with arrays
by chipmunk (Parson) on Apr 21, 2001 at 00:55 UTC
    Does the command being executed by system() produce any output?
      If I understand your question my answer would be yes. When the script is run from the command line, the system call works properly and sends the correct report to the correct printer. As far as when it is run from the web page, I don't know. The only info I have is the INTERNAL SERVER ERROR and the error_log of:
      malformed header from s cript. Bad header=bwcinvoice.rdf: /blah/blah/blah/blah/blah/test2.pl

      Does that answer help? Sorry if it is not very clear. I am very confused right now.

      Prince99

      Too Much is never enough...

        When you are sending back data from a CGI, the FIRST THING that gets printed to STDOUT (which is where output from an external program is probably going to go) MUST be a properly-formed HTTP header. What seems to be happening here is that you make the call to system before you print your header, and so the first thing the webserver sees from your CGI is that external program's output.

        One way around this problem is to use backticks (``) instead of system to execute your external program, although this is potentially less safe than the method you're currently using (since the string that appears in the backticks contains user-entered data, a nasty user might have your command execute something nasty).

        my $output = `@args`;

        the backticks redirect the output from the program to the variable you specify, and won't print them to STDOUT. If you decide to follow this advice be *sure* to use taint mode (add -T to the #! line) and untaint any user-entered data. See perldoc perlsec for more info.

        Another way to do it that's less fraught with evil cr4X0r3r peril is to stick with your system call, but to redirect its output from STDOUT to somewhere else. If you want a log of your external program's output, append ">> external_command.log", or, if you don't care what the output is, "> dev/null") to your @args array. But use taint mode any time you're passing user-entered information to a shell.

        HTH