>rsh (and ssh) use \n~x to perform certain actions (x=.
>disconnects, x = ^Z stops the process, and a few more). I think that a
>command mode could be attached to, say, x=\n, without breaking the
>existing actions. This is a little different from telnet, which drops
>you to the command prompt immediately when you press the escape
>character, by default ^]. I haven't used kermit for a few years, but I
>seem to remember that it is more like telnet than rsh in this respect.
Yes, and that's mainly what I was pointing out as it sounded like
this was the path the "feature" was heading down. Having an
non-allocated key (/n~/n?) trigger the command mode sounds perfect.
>> If you turn this into a "command" mode requiring additional
>> keys (ala Kermit?) you will break lots of existing scripts that might
>> depend on this capability (I've only ever once done such a thing, and
>> would never do it again, esp with perl available).
>
>Are you saying that you used the escape character from scripts? To me,
>the escape character looks like a feature designed for interactive use
>only. When doing, for instance, tar cf - | ?sh ..., I think the
>escape feature *should* be disabled by default, but I haven't tested
>what rsh and ssh do when used non-interactively. Otherwise, bad things
>may happen if the tar file happens to contain the string \n~.
Uh, yeah, I did it from a script, I needed to suspend the input (but
still receive the output... ugh, never again!)
I'm not sure if someone else was stupid enough to do such a thing, but
thought it might be worth mentioning...
>I think that the Right Thing is to enable the escape character by
>default iff stdin is connected to a tty.
Agreed. And if the user specifically wants it? Ala, -t option on
ssh or some such?
satch
