Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
I've been playing with an idea that would involve running a machine over a delay-tolerant mesh network. The thing is, each packet is precious and needs to be pretty much self contained in that situation, while modern systems assume SSH-like continuous interaction with the user.
Has anyone heard of anything pre-existing that would work here? I figured if anyone would know about situations where each character is expensive, it would be you folks.
You're viewing a single thread.
The 'ed' editor was designed for high latency networks. I would pull on that thread. That is, in your shoes, I would read up on 'ed' and related tools.
Delightful!
"Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!"
Gave me a giggle. That 100k loss has got to hurt for a user who still tries to run 'vi' on a classic system, I imagine.
Edit:
Another gem:
"Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity."
I would pull on that thread. That is, in your shoes
Directions unclear; shoelaces tangled
Ed is great (in this context). I think there's been posts about it on here before. It's just a text editor, though.
Yeah. I've had mentors regail me of other tools they used alongside 'Ed', but I wasn't listening very attentively. Hopefully that's something that can be dug out of the history of the Internet.
I would definitely choose the old reliable stuff over something new and fancy, if I had this use case.