4 ms·
What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to m
by saltcured 3y ago
What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to mimic the existing rsh CLI experience for basic things, just as scp tried to mimic rcp.
To me, this is a bit like the scp vs sftp topic. You really want a new remote-invocation CLI that throws away the rsh compatibility concept and is designed with "modern" goals. And, it probably needs new protocol elements to properly engineer it.
But this is also similar to the "system" callouts from multiple languages which abdicate responsibility and pass a command string to an external interpreter. Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments?
- rollcat 3y ago> Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments? Remember APIs are made for humans, (assuming we're talking local processes) nobody can stop you from using raw fork(2)+pipe(2)+execve(2) every time, yet you will usually reach for popen(3).