IIUC the `scp` cmdline will still exist it'll just use the sftp protocol behind the scenes instead of the eco protocol. Note that the deprecation is about the protocol not the cli.
It'll break a lot of valid functionality that relies on it, and the only case I can see presented as to why is for situations when servers choose to offer scp when they should have chosen to offer sftp.
Complaining that some people hand out shell access and this creates a "problem" that they gave people access to shell commands verges on ridiculous.
Having servers offer scp instead of ssh is not the only problem.
What about this part of the article:
Finally, while the danger is remote, it is worth noting that a local file name containing `backticks` (a file named `touch you-lose`, for example) will be handled the same way on the other end; if a user can be convinced to perform a recursive copy of a directory tree containing a file with a malicious name, bad things can happen.
You can deprecate something while still letting people add it back into their PPA manually. If you absolutely need an deprecated tool, no one's going to stop you: it's linux. Heck, just com,pile it from source and be on your merry unsupporteed way.
The scp protocol is literally deprecated: what do you not agree with? The idea (and already being worked on) is to change the scp command's underlying code so that it behaves exactly the same as before, all your scripts will keep working just fine, it just won't use the now dead scp protocol under the hood and will instead use the universally supported sftp protocol.
Which probably won't work in a lot of cases. I just got burned by the very minimal raspian ssh server they ship by default.
First it didn't support the authentication method I wanted to use, and then it didn't have any port forwarding ability. I'm betting it doesn't have sftp support either.
ssh cat /foo/bar > /bar/baz
ssh tar c /foo | tar x -C /bar
mostly because variants such as vagrant ssh or docker-machine ssh, cross-product with the remote target being any weird platform like solaris or a limited busybox or has sftp disabled
I've found many people either forget (or never knew) that pipes have a buffer, and that buffers are very useful when you are dealing with potentially bursty throughput.
In a previous team where we dealt with shipping around lots of ZFS snapshots (where both the performance of reading from disk can vary based on the ARC and filesystem metadata) and occasionally using VPN tunnels on public internet links, pv to get even larger pipe buffers than standard was often a huge performance equalizer. Readers read as fast as they can, writers write as fast as they can, and the buffer massages any variability in the middle.
It's not just the buffer, it is the PIPE. Specifically, pipelining that streams one file after another, without an idle period of waiting for the round-trip acknowledgements of one file receipt prior to sending the next. Using rsync over ssh has the same massive benefit for transferring many files, even if there is no existing data to make use of its differential transfer mechanisms.
(Those extra mechanisms are usually beneficial in WAN scenarios as well, except when you have high speed links, in which case blasting the full files may be faster than doing the IO to figure out comparisons and skip transfer.)
I was transferring files to an Android device, and adb push wasn't working for some reason. It would hit an error and kill the adb connection until I re-plugged the USB.
Ah yes, that one too. Used it a couple of times straight with a /dev/sda to best effort salvage data from a broken but running remote system I knew would not reboot as is.
Huh, pleasantly surprised to learn that dd correctly handles the truncated final block of a not-multiple-of-512-byte file; could have sworn that didn't work at some point.
SUS specifies that dd should do the "right thing" with input with non-integer number of blocks input, that is pad it with zeros if conv=sync, just pass through shorter otherwise.
In my, and possibly their defence, I read the article, and missed the one line in the second to last paragraph which states that it is the protocol being replaced. The way the article opens, coupled with the title makes that an easy point to miss.
I've become a big fan of military-style Bottom Line Up Front writing[0]. In this case, the article could have started with "we're deprecating the scp protocol and updating the scp command line utility to use the sftp protocol instead."
A new command with similar cli but different name is in process but it will not (and can't) support all features of scp so it can't be a drop in replacement and as such you can't name it scp as this would brake existing systems.
Thanks for pointing that out, even after reading the article I had not understood that to be the case. I suspect doing so will have issues of its own however.
