At 06:20 AM 3/8/00 -0700, Tom Christiansen wrote:
>I glanced through perlport and README.vms alike, yet remain unclear
>as to how much VMS supports the myriad Unix-style IPCish syscall
>facilities and related practices. Is there some other document
>that describes this in better detail somewhere?
There's perlvms.pod, which has some of this stuff.
>I was wondering whether VMS supports any of the following constructs,
>and if so, whether there are any noteworthy variations from the
>expected Unix models. (Note: Some of these are *no*great*loss* if
>missing, and perhaps even a feature. :-)
>
>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.
>1. flock() (don't semantics differ; eg, mandatory?)
Nope. VMS has mandatory filelocking, enforced by the filesystem.
>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.
> $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)
>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. :)
>4. Explicit pipes
>
> pipe(PIPE1, PIPE2)
Yep.
>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.
>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
snapshotted at the fork and the exec spawns off a subprocess with that
snapshotted state, then rolls the parent back (sort of) to where it was at
the fork() snapshot time)
>7. Making copies of existing filehandles (&)
>
> open(OUTCOPY, ">&STDOUT")
> open(INCOPY, "<&STDIN" )
Yep.
>8. Making aliases through existing file descriptors (&=)
>
> open(OUTALIAS, ">&=STDOUT")
> open(INALIAS, "<&=STDIN")
> open(BYNUMBER, ">&=5") # fdopen(5, "w")
Yep.
>9. Sockets
>
> * Domains: Internet (AF_INET) and Unix (AF_UNIX aka AF_LOCAL)
Yes and no. We could use VMS' mailboxes to do AF_UNIX, but nobody's written
the wrapper code yet.
> * Protocols: TCP, UDP, raw IP, (etc?)
Yep.
> * socketpair for double pipes
Nope.
>10. Named pipes (FIFOs)
No, though these could also be done with mailboxes
>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)
>Also, if under VMS I print "\n" down an output pipe or socket, does
>the other side get one byte or two, and if so, which? What about
>reading?
It depends. :(
You'll get either a bare LF or a CRLF pair. For sockets it's an LF IIRC,
while for mailboxes the answer is "it depends". VMS' mailboxes are
record-oriented devices, so the \n gets turned into a record separator. How
it gets reconstituted (if it even does) at the other end depends on how the
other end has the mailbox open.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
