At 11:41 AM -0600 5/29/03, Michael Downey wrote: >You shouldn't have to set up mailbox piping because the system() call is a >blocking call. Therefore, any sharing of file I/O is not an issue as there >shouldn't be a way to system() off a large number of process all reading >from the same file.
Though safe_popen implements pipes for piped open() as well as for system() and backticks. > >> My own opinion is that when you do system(), the subprocess shouldn't >> be taking any input from sys$input at all...it should have it's input >> set to NL: ... if you want a subprocess that gets input, you should >> be using open(X,'|some_command'). >> >What about when you are writing an interactive script and you want to call a >program that also is interactive? We do currently support that by inheriting SYS$COMMAND from the parent. >subprocess should inherit stdin, stdout and stderr. And they will >unless you wrap them in a DCL script. Hmm. I think once you are running a DCL procedure you are implicitly asking that SYS$INPUT be the command procedure, though SYS$COMMAND remains your terminal for an interactive session. For example: $ type foo.com $ show logical sys$input $ show logical sys$command $ @foo "SYS$INPUT" = "_BRIANA$DKB100:" (LNM$PROCESS_TABLE) "SYS$COMMAND" = "_BRIANA$TNA21:" (LNM$PROCESS_TABLE) However, this is not necessarily an argument against your approach, since the logical redefinitions that take place in vmspipe.com are user-mode and will persist only for the execution of the piped command and thus shouldn't confuse DCL in reading the rest of the .COM file. 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: --- vmspipe.com Sat May 24 00:49:00 2003 +++ new_vmspipe.com Thu May 29 13:24:59 2003 @@ -6,7 +6,10 @@ $ perl_del = "delete" $ pif = "if" $! --- define i/o redirection (sys$output set by lib$spawn) -$ pif perl_popen_in .nes. "" then perl_define/user/name_attributes=confine sys$input 'perl_popen_in' +$ pif perl_popen_in .nes. "" +$ then perl_define/user/name_attributes=confine sys$input 'perl_popen_in' +$ else perl_define/user/name_attributes=confine sys$input sys$command +$ endif $ pif perl_popen_err .nes. "" then perl_define/user/name_attributes=confine sys$error 'perl_popen_err' $ pif perl_popen_out .nes. "" then perl_define sys$output 'perl_popen_out' $! --- build command line to get max possible length [eop] > Also why don't we use the C RTL >routines? Both system() and popen() are available. I do know that prior to >version 7.2 of VMS many of the C RTL routines are missing or have problems, >but in the current version of VMS the C RTL seems to be well supported and >has most of the bugs worked out of it. Yes, there has been *huge* improvement in the C RTL in recent years, but the piping implementation was still very buggy as of 7.2. Previous to Perl 5.6.1 we were using the C RTL for popen(), but a lot of piped I/O was just hanging in various deadlock conditions. Chuck cooked up what we currently have to get around these problems. It works rather well and has the added advantage of working on older VMS versions, which he and a lot of other people still use. Long term I'd like to see his piping implementation configurable so that with the flip of a switch we could get either his version or the C RTL version. That way if the C RTL version is ever better, we can use it when and where available. >Really I'm coming from the point of view of portability. If Perl doesn't >work similar on one platform as it does on the other then I'd say we are >losing a large part of what makes Perl so great. I think we're all in agreement about that. How to get there is not always as clear as it could be. >I'm hoping for more input on this problem as I have just recently started >looking into the guts of VMS Perl. I have programmed on VMS extensively but >would think that others would be more familiar with the VMS code. Right now >we only have systems running 7.2 or better and we likely will be moving >everything to 7.3-1 as it seems to have the best support for threads and the >C RTL. So testing on earlier versions is a bit hard for me. Thanks for getting involved. I think we should do something along the lines you are suggesting, but this can get to be pretty twisty stuff so don't be put off if we want to discuss a bit before committing to a particular solution. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
