scp does not work: wrong bashrc

When I tried to use scp to copy a file on a distant machine:

scp -v filename username@xxx.xxx.xxx:/home/username

it looked as if the SCP command works but the file is not copied. The interactive option (-v) does not provide any hints.

The problem seems to reside in the bash environment. If I remove the different parts of the bashrc, it works. So, you need to disable the bashrc. It seems to be known that when called by SSH, an SCP command calls the user’s login shell. To disable it, add this line in the .bashrc file in the home directory:

[ -z "$PS1" ] && return
Please follow and like us:
error
This entry was posted in Linux and tagged , , . Bookmark the permalink.

3 Responses to scp does not work: wrong bashrc

  1. David Regal says:

    Thank you.

    Copying using scp was returning the properties on a file.

    E.g. “C0644 95168 file.txt”

    This helped me pinpoint my problem to something in my .bashrc file on the remote. Having the line ‘[ -z “$PS1” ] && return’ near the top of .bashrc seemed to fix it.

  2. Scott Bollig says:

    Thank you for this one. Never had trouble before, but I just setup a new server and I always copy my .bashrc. I noticed that the command:

    [ -z “$PS1” ] && return

    was NOT at the top. It was the second line after and echo command. Once I moved it to the first line it worked.

    Thanks again.

  3. Phlip says:

    Thank you! I had a command in my bashrc that was supposed to set up some things by sending a bunch of escape sequences to the terminal… I didn’t think about the fact that these would be sent across scp calls and such too!

    To make it worse, since the escape sequences are invisible when printed to the terminal, running “scp -v” didn’t help at all, since it appeared that the data it was receiving was correct!

    A minor suggestion: depending on exactly what it is in your bashrc that is causing problems, a better test could be:
    [ -t 1 ] && echo “things”
    or:
    [ -t 1] || return
    depending on whether it makes more sense for the behavior to be conditional on whether bash is *interactive* or whether it’s *connected to a terminal*. For my configuration, it was more important whether it was connected to a terminal, so I used -t 1 instead.

Leave a Reply

Your email address will not be published.