[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[patch]gnu tar 1.19, rtapelib.c
From: |
John E. Malmberg |
Subject: |
[patch]gnu tar 1.19, rtapelib.c |
Date: |
Mon, 31 Mar 2008 22:51:35 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_617_MHz; en-US; rv:1.7) Gecko/20040621 |
This is what VMS needs to be able to issue the rsh command.
VMS does not really fork(), what happens is that the fork() calls a
routine named vfork() via a macro which sets a longjump to appear to
return twice.
First it vfork() returns with a status of 0 to pretend to be a child,
but it really is not a child process, it is still the parent.
When the exec*() call is made, at that point a child is created, and the
code executes the longjump to return again from the vfork(), this time
with the pid of the child.
So that means that on VMS you do not close the parent side of the pipes.
A special VMS specific call redirects the pipes to the next child
instead of using the dup() routine.
-John
address@hidden
Personal Opinion Only
--- /src_root/tar-1.19/lib/rtapelib.c Sun Aug 12 02:57:15 2007
+++ /stage_vms_src/tar-1.19/lib/rtapelib.c Mon Mar 24 00:21:28 2008
@@ -487,6 +487,11 @@
{
/* Child. */
+#ifdef __VMS
+ decc$set_child_standard_streams(
+ to_remote[remote_pipe_number][PREAD],
+ from_remote[remote_pipe_number][PWRITE], -1);
+#else
close (STDIN_FILENO);
dup (to_remote[remote_pipe_number][PREAD]);
close (to_remote[remote_pipe_number][PREAD]);
@@ -496,7 +501,7 @@
dup (from_remote[remote_pipe_number][PWRITE]);
close (from_remote[remote_pipe_number][PREAD]);
close (from_remote[remote_pipe_number][PWRITE]);
-
+#endif
sys_reset_uid_gid ();
if (remote_user)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [patch]gnu tar 1.19, rtapelib.c,
John E. Malmberg <=