From: Peter ....... To: firstname.lastname@example.org Date: Tue, 3 Jun 2008 03:31:09 +0000 (UTC) Subject: Re: Switching to Screen That is a brilliant idea! >> ........... >An ounce of prevention is worth a pound of cure. >A simpler approach is to launch screen in your *profile >script, and never leave it without a clearcut reason. :-) >(As i discussed in my bash talk at UUASC way back when, >or last week at IEEE-CS/Lilax). > >Regards, Dallas E. Legan II / email@example.com / firstname.lastname@example.org >..........Well, to merit such accolades, maybe I ought to fill in on what I mean by this. Typically, I launch screen in my ~/.bash_profile script with the phrase: screen -R Which usually does a good job of grabbing any detached screen sessions that may be floating around, and if any aren't, it launches a new one. Now, what are some 'clearcut reasons' to leave screen?
- I've encountered three instances I can recall.
- I accidently cat some file to standard out, it turns out it wasn't really a text file, but a binary, and it messes up the console so bad 'stty sane', 'reset' etc. fail to clear things up. Sometimes, I've found detaching screen, trying reset and such will get the tty working properly before you reattach. I seem to recall instances you might need to logout and then 'kill -HUP 1' to restart intit and be really serious about this sort of thing.
- I'm running some sort of remote console connection with screen at the opposite end. I like to use ssh inside kermit for this sort of thing, and if you are running screen at both ends you have to escape your screen escape sequences to the other end of the remote session. I find it simpler to login locally on an inittab controlled vitual console, not runing screen, and that way I can just skip the escape key to send screen key sequences to the remote end of the session.
- Mouse responsive console apps like Lynx haven't responded to the rodent in the past for me when run in screen. I recall doing some surfing in the past to investigate this and finding some posting about how screen doesn't handle mouse keys and isn't able to pass them on to the application. You can run Lynx in another inittab controlled console, or like I do, I have a short Lynx EXTERN script to use startvt to open another console for the text mode browser if I want to use the mouse. There are probably other apps with this problem. I should note that gpm is not one of them, it's basic cut and past operations seem impervious to it.
But Wait, There's MoreThat's not as hardcore as you could get. In the /etc/login.defs file there is a section:
# # Instead of the real user shell, the program specified by this parameter # will be launched, although its visible name (argv) will be the shell's. # The program may do whatever it wants (logging, additional authentification, # banner, ...) before running the actual shell. # # FAKE_SHELL /bin/fakeshellYes, you read that correctly. I think a main purpose of this feature is insert programs like 'script' for auditing or simple minded honeypot applications (and I've heard of intruder's being trapped by similar methods). However, I have successfully put in: FAKE_SHELL /usr/bin/screen commented out the screen in ~/.bash_profile, and the program in question did run before bash ran it's profile script. Capabilities like this and those of the pam_env module start to override the shell startup scripts considerably. An alternative plan might be to add /usr/bin/screen to /etc/shells, add a line shell /bin/bash into /etc/screenrc or ~/.screenrc, and replace your default shell in /etc/passwd with /usr/bin/screen. I have to confess to not experimenting with this to any serious extent. Hopefully, you've gotten something out of this diatribe. It's mostly pulled from my bash and password talks (with maybe a bit from an improvised section of the 'Greatest Hits' talk) given initially at UUASC meetings. I felt like this was an opportunity to consolidate some of this information.