Still would love if desktop terminal emulators would implement the zmodem receiver side, so that you can ssh into some host of your choice and just type "sz" to copy arbitrary files of your choice onto your local system.
It’s just not the same as having transfers available on the remote command line. I have a program I wrote that maintains a local server with a port forwarded over SSH. Then on the remote side I have a client program that sends a file(s) (or folder) back to my local computer. It can either save the file or open it, depending on the command I ran.
This type of automatic transfer makes it very convenient to generate figures on a server (where the data lives) and then view them locally. It’s a much better workflow than having to use sshfs or scp.
What I wrote is really quite similar to an old transfer program like zmodem with the added feature of auto opening a file if I choose.
Once you mount everything as local with rclone, transferring protocols have no sense, everything should be part of a filesystem. Plan9 did it right, there's no difference between local and remote once you get the grasps of 'bind'.
But if the analysis programs are in a different server or you don’t want to transfer 100s of GB of data to the local machine for processing, you still want to have the ability to selectively transfer individual files.
It doesn’t matter if you mount a remote server locally… unless your data is of a trivial size, you still want to do the processing remotely.
I see this as a theory vs practice difference. In theory having one unified file system is great and the way to go. In practice… there are issues.
screen supports zmodem if you have lrzsz installed. Just put "zmodem catch" into your ~/.screenrc , then ssh while in screen and execute sz/rz on the remote end. screen will automatically recognize the control sequence and prompt with a completed sz/rz command - enter executes and sends/receives the file.