Charles Bailey <[EMAIL PROTECTED]> writes:
> | 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:
>
> 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.
I tried out the CLI symbol scheme, and it seems to work just fine...
I'm using "PERL_POPEN_(CMD|IN|OUT|ERR)" for the symbols. Good scheme,
much better than trying to encode/decode to evade DCL quoting.
> | 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:
...
> | 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?
No, but putting that in doesn't get rid of the EOFs. In fact, I put
in
$ Deassign Sys$Input
$ Deassign Sys$Output
$ Deassign Sys$Error
$ show log/proc/output=pipe.out sys$*
$ exit
So I *know* the logicals are _NLA0: when the subprocess exits (and
I know from other tests where I write out stuff after running Perl
in the subprocess that the EOF comes at subprocess exit, not at Perl
rundown).
But still there's EOFs. Maybe there's some other bit of RMS rundown
that isn't getting done before process rundown.
I also tried using (instead of "$define sys$output ..."):
$ open/write/share sys$output 'perl_popen_out'
etc....this didn't produce anything useful at all (i.e., didn't even
work as output... show log/proc after the open doesn't show a
new sys$output assignment). Hmm...just tried from a command line,
and it doesn't work there either.
To summarize:
EOFs come at subprocess exit, so Perl isn't producing them
EOFs occur whether SYS$OUTPUT is explicitly defined in LIB$SPAWN,
defaulted in LIB$SPAWN (old pipe scheme),
or by DEFINE in command procedure (new scheme)
doing "open sys$output" doesn't seem to work...
So, there's three choices:
1. live with spurious EOFs from subprocesses of subprocesses(ugh++)
2. set SYS$OUTPUT to NL: if not piping out of subprocess (ugh)
3. try to filter the EOFs (ugh)
Your level of "ugh" may differ from mine, so when I send out a patch
a little later with option 3 (old default is 1, my patch from a few
days ago is 2), please express your level of "ugh" to be applied to the
three options.
-----------------------------------------------------------------------
One further issue for comment: when Perl exits (whether subprocess or
not) the SYS$EXIT call causes any error message to be printed to
SYS$OUTPUT and SYS$ERROR. I know there was some discussion long ago
having to do with unixish/vmsish exit status, but this is slightly
different.
The test suite has numerous places where Perl is made to purposefully abort;
resulting in a slew of
%SYSTEM-F-ABORT
messages...some of which are handled sensibly, others not.
Unlike previously, we can now get rid of those messages if desirable for
piped Perl subprocesses. Is it desirable? The numeric exit $STATUS from
Perl is still available.
And if you're running Perl from the command line, you still get the
messages. It's only piped Perl where they would be supressed. It's
a single "set message/no..." line in PERL_ROOT:[LIB]VMSPIPE.COM, so
it can be commented or uncommented to suit...at least for testing
purposes.
There seems to be a few places in the test suite where we really look
for error message strings (lib/vmsish.t), and most of the other places
any "VMS-handling" consists of trying to get rid of VMS error messages.
Personally I'd be happy if the error messages just went to SYS$ERROR, but
that doesn't seem to be an option.
--
Chuck Lane [EMAIL PROTECTED]
