[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rsync
Subject:    Re: configure --with-rsh=ssh
From:       Wayne Davison <wayned () users ! sourceforge ! net>
Date:       2001-06-25 18:28:35
[Download RAW message or body]

On Mon, 25 Jun 2001, Dave Dykstra wrote:
> On Fri, Jun 22, 2001 at 05:26:52PM -0700, Wayne Davison wrote:
> > I think a better method would be for rsync to have a default blocking
> > setting for the default remote shell (perhaps configurable along with
> > what the remote shell is), and then let the user override the proper
> > remote shell and blocking behavior for their transport.
>
> How is that different from the way it is now?

We don't currently have a means of specifying what default blocking is
needed for the default shell.  For instance, if we're on a system that
has an rsh that needs non-blocking IO, we need to be able to specify
"use rsh" and "use non-blocking IO" at configure time.  I was also
thinking that it would be nice to get rid of the name-checking kludge,
but that would affect backward compatibility and would probably be
undesirable for that reason.

One possible solution is to add a means of indicating both blocking IO
and remote-shell in one item.  For instance, if we made a leading '@'
indicate blocking IO, someone could set their environment variable to
"@rsh" to indicate they wanted to use a blocking IO rsh.  If we made
things clean where no name-checking was done, this would mean that the
commandline option "-e rsh" would default to non-blocking IO (a change
in behavior) requiring the user to type either "-e @rsh" or use the
--blocking-io option.  Such an incompatibility may be too big a price to
pay for a clean codebase, so we could instead add support for a double-@
to indicate that we need non-blocking IO.

Here's a simple patch that leaves the current name-checking kludges
alone and just adds support for one or two leading '@'s.  It assumes
that my previous rsh/remsh change to main.c is not present, and works
with or without the rest of my --with-rsh patch:

Index: main.c
--- main.c	29 May 2001 14:37:54 -0000	1.127
+++ main.c	25 Jun 2001 17:56:50 -0000
@@ -168,8 +168,19 @@

 		server_options(args,&argc);

-
-		if (strcmp(cmd, RSYNC_RSH) == 0) blocking_io = 1;
+		if (*cmd == '@') {
+			if (*++cmd == '@') {
+				cmd++;
+				blocking_io = 0;
+			} else
+				blocking_io = 1;
+			args[0] = cmd;
+		} else if (strcmp(cmd, "rsh") == 0
+#if HAVE_REMSH
+			|| strcmp(cmd, "remsh") == 0
+#endif
+		    )
+			blocking_io = 1;
 	}

 	args[argc++] = ".";

So, what do you think?  Too kludgy?  Just kludgy enough?

A sysadmin that needed a blocking-IO rsh as the default could then use
"--with-rsh=@@rsh" as a configure option (with my --with-rsh patch).

Question:  Are these latest "with" options misnamed?  It seems to me
that configure uses the "with" prefix for packages, not configure
choices.  Perhaps "--with-rsync-path" should be changed to be
"--default-rsync-path" and "--with-rsh" should be changed to
"--default-rsh".  (However, open-ssh seems to violate my assumed
rule pretty thoroughly, so maybe I'm wrong on this.)

..wayne..

[prev in list] [next in list] [prev in thread] [next in thread]