the RSYNC_CONNECT_PROG command instead of using
       the default shell of the system() call.

USING RSYNC‐DAEMON FEATURES VIA A REMOTE‐SHELL CONNECTION
       It is sometimes useful to use various features of an rsync daemon  (such
       as  named  modules) without actually allowing any new socket connections
       into a system (other than what is already required to allow remote‐shell
       access).  Rsync supports connecting to a host using a remote  shell  and
       then spawning a single‐use "daemon" server that expects to read its con‐
       fig  file in the home dir of the remote user.  This can be useful if you
       want to encrypt a daemon‐style transfer’s data, but since the daemon  is
       started up fresh by the remote user, you may not be able to use features
       such as chroot or change the uid used by the daemon. (For another way to
       encrypt  a daemon transfer, consider using ssh to tunnel a local port to
       a remote machine and configure a normal rsync daemon on that remote host
       to only allow connections from "localhost".)

       From the user’s perspective, a daemon transfer via a  remote‐shell  con‐
       nection  uses nearly the same command‐line syntax as a normal rsync‐dae‐
       mon transfer, with the only exception being that you must explicitly set
       the remote shell program on the command‐line with the --rsh=COMMAND  op‐
       tion.  (Setting  the  RSYNC_RSH in the environment will not turn on this
       functionality.) For example:

           rsync ‐av ‐‐rsh=ssh host::module /dest

       If you need to specify a different remote‐shell user, keep in mind  that
       the user@ prefix in front of the host is specifying the rsync‐user value
       (for a module that requires user‐based authentication).  This means that
       you  must  give  the ’-l user’ option to ssh when specifying the remote‐
       shell, as in this example that uses the short version of the  --rsh  op‐
       tion:

           rsync ‐av ‐e "ssh ‐l ssh‐user" rsync‐user@host::module /dest

       The  "ssh‐user"  will be used at the ssh level; the "rsync‐user" will be
       used to log‐in to the "module".

       In this setup, the daemon is started by the ssh command that is  access‐
       ing the system (which can be forced via the ~/.ssh/authorized_keys file,
       if  desired).  However, when accessing a daemon directly, it needs to be
       started beforehand.

STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS
       In order to connect to an rsync daemon, the remote system needs to  have
       a  daemon already running (or it needs to have configured something like
       inetd to spawn an rsync daemon for incoming connections on a  particular
       port).  For full information on how to start a daemon that will handling
       incoming  socket  connections, see the rsyncd.conf(5) manpage -- that is
       the config file for the daemon, and it contains the full details for how
       to run the daemon (including stand‐alone and inetd configurations).

       If you’re using one of the remote‐shell  transports  for  the  transfer,
       there is no need to manually start an rsync daemon.

EXAMPLES
       Here are some examples of how rsync can be used.

       To  backup  a  home directory, which consists of large MS Word files and
       mail folders, a per‐user cron job can be used that runs this each day:

           rsync ‐aiz . bkhost:backup/joe/

       To move some files from a remote host to the local host, you could run:

           rsync ‐aiv ‐‐remove‐source‐files rhost:/tmp/{file1,file2}.c ~/src/

OPTION SUMMARY
       Here is a short summary of the options available in rsync.  Each  option
       also has its own detailed description later in this manpage.

       ‐‐verbose, ‐v            increase verbosity
       ‐‐info=FLAGS             fine‐grained informational verbosity
       ‐‐debug=FLAGS            fine‐grained debug verbosity
       ‐‐stderr=e|a|c           change