"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). > > 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? > > 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. > -- 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.
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 if you set VAXC$PATH to say SYS$SYSTEM|DKA100:[BIN]|etc... then you don't have to worry about specifying the full path of your executable to run. Also all the input/output/error inheritance is handled correctly for any C program that is spawned. You can also use the decc$set_child_standard_streams() call to set up SYS$INPUT, SYS$OUTPUT and SYS$ERROR of all other programs and DCL scripts. Actually I wonder if we could use decc$set_child_standard_streams() to solve our problem. Instead of using VMSPIPE.COM we might be able to make the call to decc$set_child_standard_streams() before the lib$spawn and it might work. I don't know when I'd be able to work on this but if I get a chance I'll give it a try. Hope that makes sense, Michael Downey
