Charles Bailey <[EMAIL PROTECTED]> writes:
> ...with all patches to date except the
> revised pipe PPFs (waiting for Charles Lane's new stuff; BTW, could
> we just use a read-only DCL procedure, say Perl_Root:[lib]start_subprocess.com,
> instead of writing a temp file each time?)
Well, I like the idea of a fixed read-only file. So one would LIB$SPAWN
with a command:
@PERL_ROOT:[LIB]VMSPIPE "command to be run" in_dev: out_dev: err_dev:
and VMSPIPE.COM would have stuff like
...
$ DEFINE/LOG SYS$INPUT 'P2'
$ 'P1'
There's one ugly little problem, that I've solved in a test program but
haven't inserted into VMS.C yet: how do you deal with quotes, single and
double, in the "command to be run" string? Double quotes you can just
double up, but single quotes are annoying. Just *try* to get a pair
of single quotes ('') passed to a command procedure...in one line of DCL.
My current scheme is to use a "special" encoding of single and double
quotes in safe_popen, and have the DCL in VMSPIPE.COM decode to get
the string we really want.
The second, less tractable problem is that by putting the "command to be run"
string on a line with other stuff, we limit the length of command even below
what DCL already does. That's why I don't think a long filename for the
command file is a good idea ... and it may be worthwhile to trim
device names for the in/out/err devices ("duphy4$mba123:" -> "mba123:")
BTW, I recently put in code to allow inheritance of SYS$OUTPUT, SYS$ERROR
etc. and the problem of spurious EOFs is back, even though the
assignments are "/super" level, with "/exec" assignments in LIB$SPAWN
pointing to NL:
Here's the scheme:
char out[512];
fgetname(stdout, out)
if (strcmp(out,"SYS$OUTPUT:.;") == 0) do_pipe_trnlnm("SYS$OUTPUT",out);
...
Then the procedure is called with
fprintf(..."@%s %s %s %s", temp_command_file, in, out, err);
where the temp_command_file has a :
define/nolog SYS$OUTPUT 'p2'
Now, this does work for inheritance: subprocesses have valid STDOUT and
STDERR and pass their output back. BUT, when a subprocess terminates it
generates an EOF on its SYS$OUTPUT (apparantly not on its SYS$ERROR, but
maybe I'm not looking hard enough).
This causes a failure in t/io/openpid.t, test 10. The "ok 10" output
from openpid.t gets cut off by the EOF coming from its subprocess #4.
Since openpid.t is doing a "waitpid" before printing "ok 10", it
ALWAYS gets cut off by the EOF if the output of openpid.t is going to
a mailbox (e.g., TEST.COM's script). Run openpid.t from a terminal
and you'll get "ok 10" just fine.
I'm seeing if I can cook up a little filtering AST to remove the
spurious EOFs from a subprocess before passing them "up the chain".
Maybe it'll work, maybe it won't.
I already put in a little AST routine to read and discard any
data written to the input MBX of a terminated subprocess, between this
and the "EOF stuffed into output MBX of terminated subprocess" just
about all of the dreaded "test hangs" are eliminated.
The underlying errors, however, are still there.
--
Chuck Lane [EMAIL PROTECTED]
