information showing the progress
              of  the  transfer.   This  gives a bored user something to watch.
              With  a  modern  rsync   this   is   the   same   as   specifying
              --info=flist2,name,progress,  but  any user‐supplied settings for
              those      info      flags      takes      precedence       (e.g.
              --info=flist0 --progress).

              While rsync is transferring a regular file, it updates a progress
              line that looks like this:

                  782448  63%  110.64kB/s    0:00:04

              In  this  example, the receiver has reconstructed 782448 bytes or
              63% of the sender’s file, which is being reconstructed at a  rate
              of 110.64 kilobytes per second, and the transfer will finish in 4
              seconds if the current rate is maintained until the end.

              These  statistics can be misleading if rsync’s delta‐transfer al‐
              gorithm is in use.  For example, if the sender’s file consists of
              the basis file followed by additional  data,  the  reported  rate
              will  probably  drop  dramatically  when the receiver gets to the
              literal data, and the transfer will probably take much longer  to
              finish  than  the  receiver  estimated  as  it  was finishing the
              matched part of the file.

              When the file transfer finishes, rsync replaces the progress line
              with a summary line that looks like this:

                  1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to‐chk=169/396)

              In this example, the file was 1,238,099 bytes long in total,  the
              average  rate of transfer for the whole file was 146.38 kilobytes
              per second over the 8 seconds that it took to  complete,  it  was
              the  5th transfer of a regular file during the current rsync ses‐
              sion, and there are 169 more files for the receiver to check  (to
              see if they are up‐to‐date or not) remaining out of the 396 total
              files in the file‐list.

              In an incremental recursion scan, rsync won’t know the total num‐
              ber  of  files  in the file‐list until it reaches the ends of the
              scan, but since it starts to transfer files during the  scan,  it
              will  display  a line with the text "ir‐chk" (for incremental re‐
              cursion check) instead of "to‐chk" until the point that it  knows
              the full size of the list, at which point it will switch to using
              "to‐chk".   Thus,  seeing  "ir‐chk"  lets you know that the total
              count of files in the file list is still going to  increase  (and
              each time it does, the count of files left to check will increase
              by the number of the files added to the list).

       -P     The  -P option is equivalent to "--partial --progress".  Its pur‐
              pose is to make it much easier to specify these two options for a
              long transfer that may be interrupted.

              There is also a --info=progress2 option that  outputs  statistics
              based  on  the whole transfer, rather than individual files.  Use
              this flag without outputting a filename (e.g. avoid -v or specify
              --info=name0) if you want to see how the transfer is doing  with‐
              out  scrolling the screen with a lot of names. (You don’t need to
              specify the --progress option in order to use --info=progress2.)

              Finally, you can get an instant progress report by sending  rsync
              a  signal of either SIGINFO or SIGVTALRM.  On BSD systems, a SIG‐
              INFO is generated by typing a  Ctrl+T  (Linux  doesn’t  currently
              support a SIGINFO signal).  When the client‐side process receives
              one  of those signals, it sets a flag to output