"Michael Downey" <[EMAIL PROTECTED]> writes:
> "Craig A. Berry" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> OK, well, modifying vmspipe.com to redefine sys$input to sys$command
>> does provide the behavior Michael was looking for. It caused one
>> test failure, though, in t/lib/vms_stdio.t. That can be whittled
>> down to the following:
>>
>> ==== foo.com ====
>> $ perl
>> print "hello\n";
>> ==== foo.com ====
>>
>> $ perl -e "system('@foo');"
>>
>> whereupon we hang indefinitely. The behavior is identical with
>> backticks rather than system(). I think what's happening is that
>> when the thing being spawned is a DCL command procedure *and* the
>> first image activated in that procedure reads from SYS$INPUT, it
>> tries to read from the parent's input rather than the command
>> procedure (which is what it's expecting).
I think this analysis is correct. Maybe one should check the
first character of the command, and only redefine SYS$COMMAND
if the command doesn't start with an '@'.
>> Is the expectation of the test something we can change without
>> goofing up existing code out in the wild? Do the advantages of
>> inheriting stdin from the parent outweigh the risks of breaking
>> existing code?
Craig, does your code work for cases like this?:
$ perl -e"system('something_that_reads_sys$command')" <someinputfile.txt
Because if we really want to follow the unixoid "inherit i/o" model,
then that means that the `something_that_reads_sys$command' has to
somehow get connected up to the `someinputfile.txt' stream. VMS
doesn't share files particularly well, and certainly doesn't share i/o
streams, except from terminal-like devices (terminals, mailboxes,
network sockets)
The solution to this problem for SYS$OUTPUT is to have the subprocess
write its output to a mailbox that the parent process handles, copying
the data to the parent process's output.
But doing the same thing with SYS$INPUT is much harder. First, we'd
have to insinuate our code between the Perl I/O and CRTL I/O to let us
strip out the data that gets sent to the subprocess; we have to
have an AST-driven routine that senses when there is a read request on
a mailbox (possible, but only for sufficiently modern VMS versions)
and grabs the next CRTL I/O from the input. This is a real pain;
AST-safety of CRTL I/O is not something we can take for granted, so it
probably means a rewrite to use RMS I/O rather than CRTL i/o. (i.e.,
we have to re-implement CRTL i/o with VMS.C, adding our hooks)
So, with the available choices of "don't DO that", "inconsistency
between terminal&file input", and "monstrous complexity" I came down
on the side of "don't DO that". YMMV.
>> Side note: there seems to be a gap in the coverage of vmspipe.com
>> when it comes to spawning command procedures. A procedure may
>> activate many images, but only the first one will see the PPFs redefined
>> in vmspipe.com because those redefinitions are user-mode.
That's certainly true....IIRC, the reason that these definitions are
/user mode is for error message handling when spawning a subprocess
that runs Perl. Again, we could do some special-case treatment of
the logicals when the command starts with a '@'. It's a minor change
to VMSPIPE.COM, and sounds like a good idea.
>> --
> Hmm, Yes DCL scripts will have that problem, hadn't really thought of that.
> I believe it's something to do with how DCL manipulates the PPFs before
> being called. I'm just thinking off the top of my head, but one solution to
> this may be to do all the redirection of SYS$INPUT, SYS$OUTPUT and
> SYS$ERROR in VMS.C before lib$spawn is called. Then get rid of VMSPIPE.COM
> all together. Then our call to lib$spawn passing 0 as the input parameter
> will work correctly. The main reason we are running into this issue is the
> use of VMSPIPE.COM. If we take that out of the picture then I believe it
> will work correctly.
Here's the message to look at:
http://www.xray.mpe.mpg.de/mailing-list/vmsperl/2000-03/msg00114.html
from ages ago when this stuff first started being looked at. The following
month or so of vmsperl traffic has a lot of the early piping discussion.
The "prior state" of the piping was much like you describe; a simple use
of LIB$SPAWN. Please note the "problems with existing code" paragraph.
The current state of Perl's i/o is to redefine SYS$INPUT, etc. in "user"
mode to reflect command-line (or Perl open/close) redirection. If the
pipe doesn't explicitly redirect, then the subprocess will inherit these
redefined values.
> Just to get another plug in for the C RTL, really this is easier to handle
> using the vfork()/exec() calls. The current version of the exec calls
> support both DCL and executable files. It also supports the use of the
> VAXC$PATH logical that allow for a more UNIX like PATHing environment. So
That's nice. I run VMS6.2 and don't have a working vfork, nor a path.
Last I heard, there's even some VMS5 systems running Perl. We could
certainly have an #ifdef based on VMS version that selects CRTL
piping or our "roll our own" piping.
--
Chuck Lane [EMAIL PROTECTED]
