In practically every situation where you can use scp, you can use rsync instead, which I consider better in every regard. rsync by default works over ssh, so uses its authentication and configuration, like scp would.
If the file(s) do not already exist on the destination, you don't lose anything, but gain better syntax for specifying source and destination, better reporting, and a few other things. If the files or any subset do exist, you get a potentially massive speed up by only transmitting the differences.
It's also very useful to me to specify "-u", which doesn't overwrite newer files. Two-way sync for example is easy that way.
Given the advantages, for me it's just less mental load overall to always type "rsync" instead of "scp", no matter the situation, and only remember that syntax. The only problem is when the destination really does not have an rsync binary (note that you do not need an rsync daemon, just ssh and the rsync binary present on the destination host), which is surprisingly rare actually. Mostly when dealing with embedded, but even then there's often rsync.
cp -r foo/* bar
With rsync, I never know what to type: rsync -a foo bar
rsync -a foo/* bar
rsync -a foo/ bar/
rsync -a foo bar/
rsync -a foo/* bar/
I never quite know. Whatever I do, I always seem to end up with bar/foo/<stuff> until I trial and error my way to the right syntax.Ah, you fell into a trap already! Using foo/* like that is generally "weird", since you let the shell expand. It will, for example, miss files that start with a dot ("."). But not necessarily, it depends on what the shell does!
As for the "trailing /" syntax, I know what you mean, but once you've internalized it, it's easy.
Without trailing slash: Copy the directory (and its contents). With trailing slash: Copy what's in the directory. This makes sense, because with the / you say you want to go "into the directory" and copy then.
And the latter includes files starting with . and all of that, you don't have to worry about it, or about what the shell would do, it's all the directory contents.
So what you want for your example is:
rsync -a foo/ bar
rsync -r foo/* bar would do the same (wrong) thing as cp -r foo/* bar, for the same reasons, the syntax is the same in that regard.Semi-related: with other stuff symlinks act the same way, for example "ls foo" will show you the symlink (even if it's to a directory), "ls foo/" will traverse the symlink (and show you what's inside the directory).
rsync -avP foo bar # puts foo inside bar so bar/foo/*
rsync -avP foo/ bar # puts the the contents of foo, in bar (without making foo)
I like to add the v & P flags for verbosity & progress.That means "bar/" is just a contraction of "bar/."
For some reason I find the presence of the "." makes it much easier to reason about. Probably that because turns it into the same pattern as "rsync foo/x bar/y". Most people know what that does, even if "foo/x" or "foo/y" are directories.
Also --delay-updates is useful to minimize disruption when copying into a live directory read by a webserver or other program where you want to have a consisten state.
Basically scp logged you into the remote system just like ssh and spawned an process through a command pipe.
For one thing, this completely eliminated the ability to separate "user can run program on remote system" from a much more limited "can send/receive a file".
It's like if nfs access to a filesystem required the ability to log into the remote system.
I'm glad this seems to have been sort of addressed. I don't know if it allows more sane filesystem-access-only ssh access to a system.
If you want to retrieve a file without renaming it, sftp url-with-path-where-path-is-an-existing-file will copy that one file, non-interactively.
To rename or put a file (non-interactively), you need to do something like echo 'get/put remote-path local-path' | sftp ...