8

I want to use rsync to my remote server for which I have SSH access. I use the following command:

rsync -e 'ssh -p 22222' -rtz --delete content_dir/ user@example.com:/home/user/public_html

After entering the command, it asks for the password for the remote location. When I type it, it exits with the message,

stdin: is not a tty

How do I supply the password to rsync? The method suggested should also work when I use it in a shell script.

Prasanna Natarajan
  • 742
  • 6
  • 15
  • Apparently it does what it is supposed to do. The file transfer happened successfully. But what is the error message and should I worry about it? – Prasanna Natarajan Aug 15 '11 at 07:35

4 Answers4

19

You need to add:

[ -z "$PS1" ] && return

to the beginig of .bashrc that is located in your home dir.

Matt
  • 74,352
  • 26
  • 153
  • 180
Josh C Josh C
  • 332
  • 3
  • 4
  • 2
    Can you explain what this actually does? What does [ -z "$PS1" ] do? – rooby Mar 21 '14 at 04:56
  • 1
    @rooby, that command checks to see if the shell is running interactively. If so, it exits immediately. This makes sense since stuff in the bash configuration file isn't needed for non interactive processes, like rsync. – Tyler Collier May 30 '14 at 20:57
2

The password is being accepted here, as you've stated yourself the operation does happen.

The error message "stdin: is not a tty" is due to something in the startup script on your server attempting to process an action that should only happen for interactive logins (when you connect with ssh direct to the server, etc).

Zoe J Hendrickse
  • 21
  • 1
1

[ -z "$PS1" ] && return solves the problem but it checks whether the prompt string length equals to zero and if it does then exits. Although $PS1 will not be set in a non-interactive shell, $PS1 being of zero length doesn't ultimately mean that the shell is not interactive.

Better approach is to check the shell's current options using $-. For example [[ $- != *i* ]] && return.

Boris D. Teoharov
  • 2,319
  • 4
  • 30
  • 49
0

In case a simple return doesn't do the job, here's another approach taken from this blog article:

if `tty -s`; then
 mesg n
fi
  • tty -s checks if there's a TTY attached (the -s tells it to do so silently and just exit with the appropriate return code). tty returns the tty attached (e.g. "/dev/pts/1"). This should be safer than checking some shell variable ;)
  • mesg controls the write access to your terminal (msg n disallows writing to the (in our case non-existing) terminal), and thus requires one to be present.

On some systems (in my case Debian Jessie, but there are also reports on Ubuntu) mesg n1 is set unconditionally in either ~/.bashrc or ~/.profile. So if it exists that way, this might be the culprit.

As with the other examples, you can of course make that a one-liner: [[ $(tty -s ) ]] && mesg n. And nobody keeps you from combining the two:

if [[ $(tty -s ) ]]; then
  mesg n
else
  return
fi

Btw: According to the linked article, this fragment should go to the .bashrc of the machine you connect to (the "remote") – so if that's johndoe@somehost, this should be applied at the start of /home/johndoe/.bashrc on somehost. In my case I only got rid of the message after having applied this change on the "calling host" as well.

PS: Also check the .profile if it has a stand-alone msg n command (it did in my case). If it does, wrap it there.

1: mesg n is used to prevent other users on the machine writing to your current terminal device, which per se is a good thing – but not helpful for some rsync job ;)

Izzy
  • 1,364
  • 3
  • 32
  • 65