 
| Subject: | |
| From: | |
| Reply To: | |
| Date: | Wed, 2 Jul 2003 15:53:30 -0700 |
| Content-Type: | text/plain |
| Parts/Attachments: |
|
|
John Korb wrote:
> Note the use of "cat" rather than writing directly to the MPE program's
> $STDLIST. There apparently is some oddity in the way Apache interacts with
> MPE programs where if I generate more than about 2k bytes of output to the
> MPE program's $STDLIST, everything following the start of the record before
> the 2k boundary is reached is NOT sent to the user's web browser.
No oddity at all once you understand what is happening.
POSIX programs such as Apache tend to use buffered I/O. MPE programs tend to
use unbuffered I/O (or rather I/O that is unaware of POSIX buffered I/O).
I/O from the shell is buffered. If you have a CGI shell script that does
something like:
#!/bin/sh
echo "Content-type: text/html\n"
echo "<HTML><BODY><H1>Results</H1><PRE>"
/ACCOUNT/GROUP/MPEPROG
echo "</PRE></BODY></HTML>"
Sometimes it will work correctly, sometimes it won't and Apache will return
various "500" errors.
What happens is this -- the shell's echo statements are buffered. Sometimes
the buffer will be flushed before the MPEPROG is executed, and if so, the
unbuffered MPE output will be sent to Apache in the correct sequence.
But if those shell buffers have NOT been flushed, the unbuffered MPEPROG output
gets sent to Apache *before* the Content-type: header, thus causing a 500 error.
This same problem happens to newbie Perl CGI authors. The solution in this
case is to tell Perl to use unbuffered output, i.e.:
select(STDOUT); $| = 1;
> I tried having the MPE program issue a SETVAR command, but apparently the
> MPE variables don't ride the environment back from MPE Land to POSIX Land.
>
> So I tried invoking the shell and having it issue an "export" command. No
> luck there either.
I've dealt with this in the past by having the child program print a shell
command string to be executed by the calling shell script, i.e.:
eval $(childprog parm1 parm2 parm3)
Make childprog return a string like "result=OK; pin=1234". Once the shell
script evals that string, voila, you have the variables in the shell's environment.
Note that if you are using this technique, take extra care to make sure that
childprog can't be subverted by hackers to return arbitrary shell commands to
be executed.
--
[log in to unmask]
Remainder of .sig suppressed to conserve expensive California electrons...
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|
