At 3:03 PM -0600 5/29/03, Michael Downey wrote:
>"Craig A. Berry" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> In fact, a more low-tech way to get the behavior you are looking for might
>be to put
>>
>> $ define/user_mode sys$input sys$command
>>
>> into vmspipe.com. I guess that would look something like the following,
>though I haven't tested this:
I have now at long last; see below.
>From my initial testing this looks to work correctly with just this change.
>I have pulled out my code in VMS.C and added this into the VMSPIPE.COM as
>well as in the code in VMS.C that builds the temporary files if it can't
>find VMSPIPE.COM.
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.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
