At 04:12 PM 3/9/00 -0500, Charles Bailey wrote:

>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>| | At 06:20 AM 3/8/00 -0700, Tom Christiansen wrote:
>| >0. sysopen w/ normal O_* flags, especially O_EXCL (any specials?)
>| | As far as I know, yep. I've certainly used it, though I don't recall 
>any | VMS-special flags.
>
>Note that O_EXCL is the default under VMS Perl for all file opens; if you
>want shared access you need to ask specifically (for whcih the routines
>VMS::Stdio::vmsopen() and VMS::Stdio::vmssysopen() are provided).

Yep, true enough. The C-style access to RMS files is pretty lame, though. 
We really do need to get a VMS::RMS module put together at some point. 
(Yeah, I know--in what free time, exactly? :)

>| >1. flock()  (don't semantics differ; eg, mandatory?)
>| | Nope. VMS has mandatory filelocking, enforced by the filesystem.
>
>flock() isn't a native part of VMS, though some emulations exist. RMS
>locking (the intrinsic stuff) is mandatory (unless you bypass it with
>raw I/O calls) and record-oriented.

That's a pretty low-level bypass, though. IIRC you have to request actual 
disk blocks, which requires PHY_IO or LOG_IO privs.

>| >2. Running command in system (or exec) and backticks
>| >
>| >     system("cmd arg1 arg2")         # possible shell intervention
>| >     system("cmd", "arg1", "arg2")   # unmolested execvp
>| | Both work. Identically, as it turns out.
>
>Both go through the CLI.

With some magic munging. Trying some @ substitutions shows it works, 
though, and that's got me nervous.

>| >     $answer = `cmd args 2>&1`           # snag stderr, too
>| >     $answer = `cmd args 2>/dev/null`;   # discards stderr
>| | STDERR and STDOUT are mixed together on VMS for this stuff, so the 
>first is | irrelevant. The second may or may not be possible depending on 
>the command, | though that particular form won't work. (It has to be 
>VMSish looking, since | the system handles it)
>
>For commands sent to subprocesses, we can trap the command line and munge 
>it on the way out.  At the moment, we support neither construct dierctly, 
>though the "2>&1" (specifically) _is_ supported when Perl is onvoked.

That's true--perl itself knows about command redirection. I like the idea 
of having a command procedure interpose itself between perl and the 
ultimate command and pass it stdin/out/err mailboxes so we get the full 
control we don't get from lib$spawn.

>| >3. Pipe open()s
>| >
>| >     open(TO_PIPE, "|cmd")
>| >     open(FROM_PIPE, "cmd|")
>| >
>| >     use IPC::Open2;
>| >     open2(FROM_PIPE, TO_PIPE, "cmd")
>| >
>| >     use IPC::Open3;
>| >     open3(TO_PIPE, FROM_PIPE, FROM_ERR, "cmd")
>| | Yes, no, and no. Give me some time and open(IO_PIPE, "|foo|") will 
>work, as | would open2. open3's trickier, though I just had a brilliant 
>idea for a | fix. (Yes, this is a dangerous thing. :)
>
>PTYs are probably the way to go here.  The up-and-coming pipe fixes will also
>help.

Keen. I may have to send Chuck the ice cream and hot fudge, then.

>| >6. Explicit forks
>| >
>| >         if (defined($pid = fork) { parent()       }
>| >         elsif (!defined $pid)    { die "fork: $!" }
>| >         else                     { child()        }
>| | No. VMS doesn't fork, though we could open things up so a fork then 
>exec | works. There's support for that. (Basically some process state is
>It works currently, but with the caveat above.  Basically, you're OK iff
>the only thing in the child() branch above is exec qw(some child thing).

This was why I was tempted to turn on support for fork(), but I'm still not 
sure. Maybe with an explicit "use VMS::fork" or something.

>| >11. SysV IPC: messages, shared memory, semaphores
>| | Not at the moment, though we can once the VMS C RTL team gets them in. 
>(We | could write our own wrapper code but, once again, nobody's done it yet)
>
>The msg* and shm* wrappers are in newer DECCRTLs, but we don't go after 'em.
>Better still would be an interface to native global sections.

I've got no msg or shm info in the headers I've got. I've been meaning to 
take a look at implementing them on top of mailboxes and global sections, 
but time crunches keep getting in the way.

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to