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).
| >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.
| >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.
| > $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.
| >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.
| >5. Fork open()s
| >
| > open(TO_MYSELF, "|-")
| > open(FROM_MYSELF, "-|")
|
| I don't think so. Something seems to be happening, but I'm not sure what.
Here's the trick. As you note below, under VMS fork() does _not_ create a
separate thread of execution starting from the point of the call, it just sets
up context for a following exec() (and does some longjmp magic). These
implicit fork constructs do work, but afterwards both "parent" and "child"
execute in the same context (i.e. same file descriptors, same locks, etc.).
| >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).
| >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.
Regards,
Charles Baley [EMAIL PROTECTED]
