4 ms·

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 t

• stonogo 4y ago
  scp(1) has used the SFTP protocol since OpenSSH 9.0. Before that it used its own protocol.
  • krupan 4y ago
    So why remove the scp command then?
    • detaro 4y ago
      The page clearly says that the protocol is deprecated, not the command.
    • deleted 4y ago
      [deleted]
    • kibwen 4y ago
      The command isn't being removed, only support for the SCP protocol (which the scp command hasn't used for years).
• andrewstuart 4y ago
  Hoe does sftp replace scp?
  • ksherlock 4y ago
    They both can send and retrieve files, though sftp is usually interactive and scp (aside from the password) not so much. 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 ...
• stock_toaster 4y ago
  Some more information on issues with scp: https://lwn.net/Articles/835962/ https://lwn.net/Articles/835962/
• detaro 4y ago
  It doesn't say that the scp command is being removed, but that the protocol is deprecated.
• arp242 4y ago
  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.
  • m463 4y ago
    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.
    • arp242 4y ago
      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.
• anyfoo 4y ago
  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.
  • renewiltord 4y ago
    `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.
    • ryandrake 4y ago
      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.
      • anyfoo 4y ago
        > cp -r foo/* bar 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.
• renewiltord 4y ago
  [flagged]
• gbraad 4y ago
  Perhaps use zssh and sz/rz to send files. Much more convenient anyway as it allows you to switch and send files during an interactive session.