...making Linux just a little more fun!
Kat Tanaka Okopnik [kat at linuxgazette.net]
Hi, gang -
After a history of losing data to dying computers (yes, yes, I know, it's really about not backing up data adequately), I've come to prefer leaving my e-mail on remote servers rather than dealing with it locally. As a result, my non-webmail interaction is done via ssh. I've learned to run screen so that a dropped connection doesn't result in losing half-composed mail, but I haven't figured out what to do with my frozen xterm window.
What I mean by this is that I end up losing the connection, having to reconnect, and then having to kill the frozen-by-dropped-connection window. Is there a way that I can resuscitate the dead session in the existing window, rather than opening up a new xterm window and killing the old one?
Please be gentle as I expose my lack of proper terminology. I'm pretty sure I'm not describing my problem using all the right words, but I'm hoping I've come close enough for someone to figure out how I should have put it. (I'd ask my resident *nix guru to vet my question, but he's up against a deadline while running short on sleep.) I'd wait to ask my question, but I suspect I'd forget to ask, again...
-- Kat Tanaka Okopnik Linux Gazette Mailbag Editor kat at linuxgazette.net
Thomas Adam [thomas at xteddy.org]
On 19 April 2010 04:15, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote:
> What I mean by this is that I end up losing the connection, having to > reconnect, and then having to kill the frozen-by-dropped-connection > window. Is there a way that I can resuscitate the dead session in the > existing window, rather than opening up a new xterm window and killing > the old one?
Press:
~.
That's "tilda" and "dot".
-- Thomas Adam
Neil Youngman [ny at youngman.org.uk]
On Monday 19 April 2010 08:02:01 Thomas Adam wrote:
> On 19 April 2010 04:15, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote: > > What I mean by this is that I end up losing the connection, having to > > reconnect, and then having to kill the frozen-by-dropped-connection > > window. Is there a way that I can resuscitate the dead session in the > > existing window, rather than opening up a new xterm window and killing > > the old one? > > Press: > > `` > ~. > '' > > That's "tilda" and "dot".
To be absolutely clear on that, the "~." sequence kills ssh (and depends on your ssh settings leaving the default escape character unchanged). This will bring you back to your local command prompt. This will not work if the last character was not a linefeed, so it's usually best to start the sequence with the Enter key.
See the section on escape characters in ssh(1), if you need more information.
Neil Youngman
Kat Tanaka Okopnik [kat at linuxgazette.net]
On Mon, Apr 19, 2010 at 08:02:01AM +0100, Thomas Adam wrote:
> On 19 April 2010 04:15, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote: > > What I mean by this is that I end up losing the connection, having to > > reconnect, and then having to kill the frozen-by-dropped-connection > > window. Is there a way that I can resuscitate the dead session in the > > existing window, rather than opening up a new xterm window and killing > > the old one? > > Press: > > `` > ~. > '' > > That's "tilda" and "dot".
Thank you, Thomas! Tilde dot works like a charm.
Now Ben's kibbitzing over here, saying, "ah, but can you get back to the ssh session without going out and back in" (or something like that...)
But meanwhile, I'm thrilled to be able to yell, "CLEAR!" and zap the frozen thing back to life. (Okay, with the kids sleeping, I don't really yell...but I think it really loudly.)
-- Kat Tanaka Okopnik Linux Gazette Mailbag Editor kat at linuxgazette.net
Kat Tanaka Okopnik [kat at linuxgazette.net]
On Mon, Apr 19, 2010 at 08:13:48AM +0100, Neil Youngman wrote:
> On Monday 19 April 2010 08:02:01 Thomas Adam wrote: > > On 19 April 2010 04:15, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote: > > > What I mean by this is that I end up losing the connection, having to > > > reconnect, and then having to kill the frozen-by-dropped-connection > > > window. Is there a way that I can resuscitate the dead session in the > > > existing window, rather than opening up a new xterm window and killing > > > the old one? > > > > Press: > > > > `` > > ~. > > '' > > > > That's "tilda" and "dot". > > To be absolutely clear on that, the "~." sequence kills ssh (and depends on > your ssh settings leaving the default escape character unchanged). This will > bring you back to your local command prompt. This will not work if the last > character was not a linefeed, so it's usually best to start the sequence with > the Enter key.
[Nod] Thanks for the expansion.
> See the section on escape characters in ssh(1), if you need more information.
[sigh] I tried, and what I remember is a bunch of cryptic stuff that made me say, "If I understood what I wanted, I would just search for it. Since I don't know how to frame my question...":
(Now Ben's muttering something about ~B and ~R. I don't know, I just cargo-cult my computer usage. Bad user, no donut!)
I tried running a screen session locally, and then ssh to where my mail lives, but that resulted in some keystrokes getting interpreted in ways that I didn't like (e.g. the backspace key becomes something else, IOW not backspacing). This is probably a whole different question that should go under another subject line...
-- Kat Tanaka Okopnik Linux Gazette Mailbag Editor kat at linuxgazette.net
Henry Grebler [henrygrebler at optusnet.com.au]
> I tried running a screen session locally, and then ssh to where my > mail lives, but that resulted in some keystrokes getting interpreted in > ways that I didn't like (e.g. the backspace key becomes something else, > IOW not backspacing). This is probably a whole different question that > should go under another subject line...
When you ssh into another computer, you are logging in to a different environment (kinda obvious, I guess). The interpretation of some key-presses may vary.
I find the default settings of most sites really irritating. In particular, I happen to like my keys to have functions according to their position on the keyboard. This is less of a problem than in the past, since it seems that Microsoft has mandated that the key on right of the top row is labelled BackSpace. If I remember correctly, there were keyboards that labelled it Delete.
<Digression>
The one that really galls me is Control. I started using Teletypes (in the 60s). The key above Shift was Control, not Caps Lock. This continued until about the mid-90s, I guess. Then, suddenly, Control was relegated down below Shift.
I'm too old to change, so wherever I go, I remap the keyboard so that both keys produce the effect of the Control key.
</Digression>
You need to examine two parts of the problem: what ASCII sequence is the BackSpace key producing? what is the meaning assigned to that ASCII sequence?
Under FreeBSD, "showkey" echoes "raw keystrokes back at you in a printable form". Use "showkey --ascii" under Linux.
Here's what I get:
showkey --ascii
Press any keys - Ctrl-D will terminate this program
^H 8 0010 0x08
^_ 31 0037 0x1f
^[[3z 27 0033 0x1b
91 0133 0x5b
51 0063 0x33
122 0172 0x7a
The first line is what I expect from a BackSpace key. The second line is the classical value of Delete; I got it by pressing "Control-?". The rest of the lines are produced by either of the keys labelled Del.
Run the command, first on a computer where your BackSpace key works; then again where it doesn't. Are the outputs the same?
If so, then you probably need to look at stty. If not, it's a little more tricky.
On my Linux machine (to which I have sshed):
stty speed 9600 baud; line = 0; erase = ^H; -brkint ixany
The erase line is consonant with the output produced by pressing the BackSpace key (as confirmed with "showkey --ascii"). (BTW, on some Linuxes, you might need "stty -a".)
I had to jump through hoops, but I finally managed to create an environment where "erase = #". When I press the BackSpace key, I see "^H" echoed. I have to press the "#" key (Shift-3) to erase characters.
To fix the problem, I type:
stty erase "^H"NB there are 2 characters between the quotes: Shift-6 and uppercase H.
To make it permanent, add the line to $HOME/.profile
If your BackSpace key generates different ASCII output on the remote machine, you should try to create an "stty erase" command to suit.
Ben Okopnik [ben at linuxgazette.net]
On Tue, Apr 20, 2010 at 01:25:35PM +1000, Henry Grebler wrote:
> > > > I tried running a screen session locally, and then ssh to where my > > mail lives, but that resulted in some keystrokes getting interpreted in > > ways that I didn't like (e.g. the backspace key becomes something else, > > IOW not backspacing). This is probably a whole different question that > > should go under another subject line... > > When you ssh into another computer, you are logging in to a different > environment (kinda obvious, I guess). The interpretation of some > key-presses may vary.
In this case, though, the interpretation/problem came from using 'screen'; the remote host worked just fine when she just SSHed into it, but generated '^?'s instead of backspaces when she tried running 'screen' locally (my suggestion - I wanted to see if she could just drop the SSH session via 'screen' when it hung.)
The stack looks like this:
localhost -> SSH -> remotehost + vi # Works fine localhost -> SSH -> remotehost + screen + vi # Works fine localhost + screen -> remotehost + vi # '^?' instead of BkSp(I've just reconfirmed it.)
> To fix the problem, I type: > > stty erase "^H"
Yep - that's the classic solution. Making 'screen' honor that, though, takes a little more digging, and I haven't struck gold yet.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Henry Grebler [henrygrebler at optusnet.com.au]
>On Tue, Apr 20, 2010 at 01:25:35PM +1000, Henry Grebler wrote: >> >> >> -->I tried running a screen session locally, and then ssh to where my >> -->mail lives, but that resulted in some keystrokes getting interpreted in >> -->ways that I didn't like (e.g. the backspace key becomes something else, >> -->IOW not backspacing). This is probably a whole different question that >> -->should go under another subject line... >> >> When you ssh into another computer, you are logging in to a different >> environment (kinda obvious, I guess). The interpretation of some >> key-presses may vary. > > In this case, though, the interpretation/problem came from using 'screen'; the > remote host worked just fine when she just SSHed into it, but generated > '^?'s instead of backspaces when she tried running 'screen' locally (my > suggestion - I wanted to see if she could just drop the SSH session via > 'screen' when it hung.) > > The stack looks like this: > > localhost -> SSH -> remotehost + vi # Works fine > localhost -> SSH -> remotehost + screen + vi # Works fine > localhost + screen -> remotehost + vi # '^?' instead of BkSp > > (I've just reconfirmed it.) > >> To fix the problem, I type: >> >> stty erase "^H" > > Yep - that's the classic solution. Making 'screen' honor that, though, > takes a little more digging, and I haven't struck gold yet.
Sounds to me like you should try
stty erase "^_"on the remote machine.
My suggestion is to let 'screen' do whatever it wants and compensate at remotehost.
If that doesn't work, try crossing your fingers and using
stty erase "^?"
I'm a bit intrigued. I can't make it fail in the same way. What platform is localhost? What platform is remotehost?
Thomas Adam [thomas at xteddy.org]
On 20 April 2010 03:12, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote:
> Now Ben's kibbitzing over here, saying, "ah, but can you get back to the > ssh session without going out and back in" (or something like that...)
Obviously. But you could cheat. If you were to ditch screen for tmux (tmux.sf.net) you can set:
set -g set-remain-on-exit
Then you can use the "respawn-window" command get you back in to your ssh session. You could even do it all in one go.
Exercise is left to someone who wants to try.
-- Thomas Adam
Chris Bannister [mockingbird at earthlight.co.nz]
On Tue, Apr 20, 2010 at 01:25:35PM +1000, Henry Grebler wrote:
> > > -->I tried running a screen session locally, and then ssh to where my > -->mail lives, but that resulted in some keystrokes getting interpreted in > -->ways that I didn't like (e.g. the backspace key becomes something else, > -->IOW not backspacing). This is probably a whole different question that > -->should go under another subject line... > > When you ssh into another computer, you are logging in to a different > environment (kinda obvious, I guess). The interpretation of some > key-presses may vary. > > I find the default settings of most sites really irritating. In > particular, I happen to like my keys to have functions according to > their position on the keyboard. This is less of a problem than in the > past, since it seems that Microsoft has mandated that the key on right > of the top row is labelled BackSpace. If I remember correctly, there > were keyboards that labelled it Delete.
An interesting read is: https://mail-index.netbsd.org/netbsd-users/2010/04/01/msg005977.html and associated posts.
-- Chris. ======
Ben Okopnik [ben at linuxgazette.net]
On Mon, Apr 19, 2010 at 08:02:01AM +0100, Thomas Adam wrote:
> On 19 April 2010 04:15, Kat Tanaka Okopnik <kat at linuxgazette.net> wrote: > > What I mean by this is that I end up losing the connection, having to > > reconnect, and then having to kill the frozen-by-dropped-connection > > window. Is there a way that I can resuscitate the dead session in the > > existing window, rather than opening up a new xterm window and killing > > the old one? > > Press: > > `` > ~. > '' > > That's "tilda" and "dot".
Y'know, I'm glad Kat asked that question - because I had no idea, myself. Seems kinda silly, since I've known about the telnet 'escape' key sequence ever since the first cavemen starting using computers (...or something like that), but I never quite bridged the two. I suppose it's because telnet was always getting stuck, while SSH is, well, pretty darn reliable.
I do have to say, though, that living with fragile Net connections teaches its own lessons.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at okopnik.com]
On Tue, Apr 20, 2010 at 05:00:54PM +1000, Henry Grebler wrote:
> > Sounds to me like you should try > > stty erase "^_" > > on the remote machine. > > My suggestion is to let 'screen' do whatever it wants and compensate > at remotehost.
That seems reasonable - although the problem does not manifest at the commandline, but only in Vim. I dimly recall that Vim has a way to deal with that kind of error... but haven't had the spare minutes (or brain capacity) to go digging. I'm neck-deep in a project that's going to go at least another week, and my CPU is almost maxed out.
> I'm a bit intrigued. I can't make it fail in the same way. What > platform is localhost? What platform is remotehost?
ben at Jotunheim:~$ uname -a Linux Jotunheim 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux ben at Jotunheim:~$ ssh lg 'uname -a' Linux genetikayos.com 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 2004 i686 i686 i386 GNU/Linux
I don't think that's where the difference is, though. Here's some more info, edited for clarity:
ben at Jotunheim:~$ ssh lg [ben at genetikayos ben]$ echo $TERM xterm [ben at genetikayos ben]$ screen -r [ben at genetikayos ben]$ echo $TERM screen
It's quite likely that Vim knows what to do with the former, but not the latter.
-- OKOPNIK CONSULTING Custom Computing Solutions For Your Business Expert-led Training | Dynamic, vital websites | Custom programming 443-250-7895 https://okopnik.com
Henry Grebler [henrygrebler at optusnet.com.au]
>That seems reasonable - although the problem does not manifest at the >commandline, but only in Vim. I dimly recall that Vim has a way to deal
The reason that the problem does not manifest at the commandline is that bash (strictly Readline) treats both backspace (^H) and delete (^?) as "backward-delete-char". Try this:
bind -p | grep 'backward-delete-char' "\C-h": backward-delete-char "\C-?": backward-delete-char # forward-backward-delete-char (not bound)
>with that kind of error... but haven't had the spare minutes (or brain >capacity) to go digging. I'm neck-deep in a project that's going to go >at least another week, and my CPU is almost maxed out.
Well, maybe the contagion is spread via email. There I was thinking that I was immune to this stuff, when, fm if I didn't get the same problem! And I use emacs! Go figure.
I don't think I cause the problem in the same way, though I do have a good handle on how I cause the problem. For all that, I have an inelegant workaround (at least for my problem).
On an xterm press-and-hold Ctrl and then hold down the left mouse button. A menu appears. Make sure the item
Backarrow key (BS/DEL)
has a tick on its left.
The nice thing about this workaround is that you don't have to jump out of vim or emacs. As soon as you see that pressing the BackSpace key is behaving oddly, just apply the recipe.
YMMV.
Ben Okopnik [ben at linuxgazette.net]
On Wed, Apr 21, 2010 at 12:44:20AM +1200, Chris Bannister wrote:
> On Tue, Apr 20, 2010 at 01:25:35PM +1000, Henry Grebler wrote: > > > > I find the default settings of most sites really irritating. In > > particular, I happen to like my keys to have functions according to > > their position on the keyboard. This is less of a problem than in the > > past, since it seems that Microsoft has mandated that the key on right > > of the top row is labelled BackSpace. If I remember correctly, there > > were keyboards that labelled it Delete. > > An interesting read is: > https://mail-index.netbsd.org/netbsd-users/2010/04/01/msg005977.html > and associated posts.
I love it. The thread name alone - "The Chthulhoid horror that is keyboard handling in Unix" - deserves to be enshrined forever and be displayed by loyal museum staff to hushed and awed groups of children, for their proper education and moral upbringing.
The delete-vs.-backspace religious wrangle will go on long after the
human race is dust. We shall infect whatever alien race comes to destroy
us, as our final revenge.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at okopnik.com]
On Fri, Apr 23, 2010 at 06:02:07PM +1000, Henry Grebler wrote:
> > -->That seems reasonable - although the problem does not manifest at the > -->commandline, but only in Vim. I dimly recall that Vim has a way to deal > > The reason that the problem does not manifest at the commandline is > that bash (strictly Readline) treats both backspace (^H) and delete (^?) as > "backward-delete-char". Try this: > > bind -p | grep 'backward-delete-char' > "\C-h": backward-delete-char > "\C-?": backward-delete-char > # forward-backward-delete-char (not bound)It's rather odd. "screen" doesn't modify that - but it does affect how Vim works. Is it only the TERM setting, I wonder? I'll check that out later.
> On an xterm press-and-hold Ctrl and then hold down the left mouse > button. A menu appears. Make sure the item > > Backarrow key (BS/DEL) > > has a tick on its left. > > The nice thing about this workaround is that you don't have to jump > out of vim or emacs. As soon as you see that pressing the BackSpace key > is behaving oddly, just apply the recipe. > > YMMV.
...especially if you use Ubuntu. There, the default is 'gnome-terminal' - which does not have the above interface. One of the things I definitely find annoying about it. I sometimes change the default term to the real 'xterm', but most times, I can live with it.
-- OKOPNIK CONSULTING Custom Computing Solutions For Your Business Expert-led Training | Dynamic, vital websites | Custom programming 443-250-7895 https://okopnik.com
Henry Grebler [henrygrebler at optusnet.com.au]
> ...especially if you use Ubuntu. There, the default is 'gnome-terminal' > - which does not have the above interface. One of the things I > definitely find annoying about it. I sometimes change the default term > to the real 'xterm', but most times, I can live with it.
Your comment raises so many issues.
1. Why are people reinventing the wheel? What was so dreadfully wrong with xterm that someone had to fork (or, worse, create from scratch), gnome-terminal?
If extra features were desirable, why could they not be added as compile options or run-time switches to xterm?
What am I missing here?
2. The other thing that I like in "the above interface" is Log to File. Lately I have found this turned off at compile time, presumably because it is seen as a security risk.
However, as a mechanism for recording exactly what really happened during a session it beats everything else going round. I especially like the ability to turn logging on and off during a session.
3. I also love the way that xterm allows text selection with the mouse: one click for characters, two for words, three for lines. By default, right button extends/contracts the current selection; middle button pastes.
4. Whatever your tool of choice, just when you find it working how you want, it seems that someone wants to change its behaviour in a way which is insensitive to tradition.
Maybe having gnome-terminal as a separate product wasn't such a bad idea!
Thomas Adam [thomas at xteddy.org]
On Thu, Apr 29, 2010 at 10:09:26AM +1000, Henry Grebler wrote:
> 1. Why are people reinventing the wheel? What was so dreadfully wrong > with xterm that someone had to fork (or, worse, create from scratch), > gnome-terminal? > > If extra features were desirable, why could they not be added as > compile options or run-time switches to xterm? > > What am I missing here?
From XTerm's README:
Abandon All Hope, Ye Who Enter Here This is undoubtedly the most ugly program in the distribution. It was one of the first "serious" programs ported, and still has a lot of historical baggage. Ideally, there would be a general tty widget and then vt102 and tek4014 subwidgets so that they could be used in other programs. We are trying to clean things up as we go, but there is still a lot of work to do.
> 2. The other thing that I like in "the above interface" is Log to > File. Lately I have found this turned off at compile time, presumably > because it is seen as a security risk. > > However, as a mechanism for recording exactly what really happened > during a session it beats everything else going round. I especially > like the ability to turn logging on and off during a session.
script(1).
> > 3. I also love the way that xterm allows text selection with the > mouse: one click for characters, two for words, three for lines. By > default, right button extends/contracts the current selection; middle > button pastes.
I use this:
XTerm*on2Clicks: regex [^/@ \n]+ XTerm*on3Clicks: regex [^ \n]+ XTerm*on4Clicks: regex [^#$]+ XTerm*on5Clicks: line
> > 4. Whatever your tool of choice, just when you find it working how > you want, it seems that someone wants to change its behaviour in a > way which is insensitive to tradition.
I think you're missing the more obvious fact here -- gnome-terminal "fits" in with the rest of the GNOME applications, especially in terms of style. That's really important for consumers these days.
Yes, consumers. Really.
-- Thomas Adam
-- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Ben Okopnik [ben at linuxgazette.net]
On Thu, Apr 29, 2010 at 10:35:53AM +0100, Thomas Adam wrote:
> On Thu, Apr 29, 2010 at 10:09:26AM +1000, Henry Grebler wrote: > > > > What am I missing here? > > >From XTerm's README: > > `` > Abandon All Hope, Ye Who Enter Here > ''
[grin] Exactly the part I was going to cite, but you beat me to it.
> > 3. I also love the way that xterm allows text selection with the > > mouse: one click for characters, two for words, three for lines. By > > default, right button extends/contracts the current selection; middle > > button pastes. > > I use this: > > `` > XTerm*on2Clicks: regex [^/@ \n]+ > XTerm*on3Clicks: regex [^ \n]+ > XTerm*on4Clicks: regex [^#$]+ > XTerm*on5Clicks: line > ''
Oh, that's nice. For anyone following along at home, this means "add the above lines to your ~/.Xresources file (creating one if needed), then run 'xrdb -merge ~/.Xresources', which will make that configuration available to any xterms you start after that point." The effect of the above is to select, on two clicks, any part of the line that does not contain '@' signs, spaces, or newlines; on three clicks, anything that is not a space or a newline; on four, anything that is not a '#' sign or a '$' sign; and on five, the entire line.
Obviously, you could change the regexes to suit your own preferences. I wasn't aware that you could do that; nice bit of flexibility.
> > 4. Whatever your tool of choice, just when you find it working how > > you want, it seems that someone wants to change its behaviour in a > > way which is insensitive to tradition. > > I think you're missing the more obvious fact here -- gnome-terminal "fits" > in with the rest of the GNOME applications, especially in terms of style. > That's really important for consumers these days. > > Yes, consumers. Really.
Consumers who use the CLI. I boggle. Truly, I do. But you're right:
'gnome-terminal' is of a piece with the entire Ubuntu approach, and a
plain xterm just doesn't fit that model. [shrug] It's easy enough to do
System->Preferences->Preferred_Applications->System(tab) and change the
default terminal to 'Standard X terminal', if that's what you want to
do. As long as the choice is there, I'm satisfied.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *