Another surprise for me: removal of the `scp` command. I hadn't even realized that `openssh` provided a command named `sftp`; for some reason I always assumed that `scp` was using the `SFTP` protocol under the hood, but maybe I shouldn't take that for granted.
This is only tangentially related, but I'll say this here since people will appreciate knowing:
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.
`scp` provides progress etc. by default. I do have muscle memory for `rsync -irP` so it's not a problem, but default `rsync` on my Mac does not provide progress output otherwise.
I've never been able to memorize rsync's syntax such that it handles directory contents the way I want to. If I want to copy the contents of directory foo to directory bar, with cp it's easy:
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.
> 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.
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).
Note that a trailing slash means to copy the contents when using rsync, but not when using cp (which will copy the directory even if there is a trailing slash). For cp, the correct way to copy only the contents is to use `cp -r foo/. bar`. (This also works with rsync.)
The source is the only thing to worry about.
Without a trailing slash it makes a copy of the directory, and fills it.
With a trailing slash, it copies just the *Contents* of 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.
I prefer --info=progress2 over --progress - rarely do I care about the progress of individual files but I want an idea of how much longer the whole transfer is going to take.
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.
The command hasn't been removed or deprecated; just the protocol. Instead of using the SCP protocol it uses the SFTP protocol. As a user, you basically don't notice outside of some specific cases. OpenSSH has used the SFTP protocol as the default for a year or two.
I remember working on openssh years ago and when I got into scp - I was "WTF are they THINKING?" sort of thing.
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.
It's one of those "seemed like a good idea at the time" things from when the internet was essentially a bunch of universities and a lot less hostile. Originally this was all just wrappers around telnet.
