| 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:")
I wonder whether we might try having the parent place this information
into well-known CLI symbols or lnms (since the subprocess inherits both)
which VMSPIPE.COM can then translate and handle appropriately. That does
eat a small chunk of namespace, but as long as it's documented, we should
be OK. As far as I can see, it's not a security risk, since safe_popen
simply overwrites preexisting values, good or bad; we just need to make
sure to deassign the symbols after the subprocess is spawned.
| 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).
Does the command procedure say
$ Deassign Sys$Input
$ Deassign Sys$Output
$ Deassign Sys$Error
before exiting?
Regards,
Charles Bailey [EMAIL PROTECTED]
