Archive

Posts Tagged ‘screen’

[ANNOUNCE] screenenv – Physical session environment accessible within screen

June 9th, 2009 4 comments

screenenv is a gadget that should make your applications within GNU Screen use the right display and ssh agent information based on which attached screen client you call them from.

The motivation is simple – I have screen session that I create on my desktop, but when on the go (or in the next room ;) with my notebook, I want to ssh -X in and be able to still open image attachments in my mutt properly.

Several approaches are possible, I chose a fairly invasive one – I hijack getenv() calls by applications and substitute few chosen environment variables (mainly $DISPLAY and $SSH_* – e.g. $SSH_AUTH_SOCK) based on their settings in the most recently active screen client attached to the current session.

Thus, you can just keep going back’n’forth between two sessions, keep working seamlessly, no explicit action is required on your part and all your applications will Do The Right Thing.

Of course, the v0.1 release has many rough edges – if a long-term application saves the getenv’d variable, then keeps checking other volatile ones, it will probably crash (that’s fixable, though; and I think this should be very rare situation in practice, most or all of the volatile variables are for one-shot use within a single process). Also, we should cache the client lookup (which involves walking all processes) at least for few seconds…

Categories: linux, software Tags: , , ,

screen in xterm and mouse reporting problems

June 8th, 2009 No comments

I’ve recently encountered a problem (on Debian Squeeze) with screen running in xterm, and applications using mouse reporting running inside – that is, an application that can be controlled using mouse while running in a terminal (in my case, elinks, and vim with :set mouse=a behaves the same although I don’t use that setting normally).

Basically, when you start the application, mouse reporting will never be switched off again (unless you do it manually or use `reset`). Not when the application exits, and (more importantly) not when you switch to another screen window!

I tracked this down to autonuke on in my ~/.screenrc. Apparently the clear screen command goes _after_ the turn-off-mouse-reporting command, nuking it in the process. I have enabled this option in the past in the hope that it will be helpful in case I inadverently trigger huge amount of data being sent (I could just “C-a -” to clear my screen. Too bad this breaks it; maybe GNU screen could be made smarter about this and not nuke escape sequences, but I have heard that its developers are fairly unfriendly, so I won’t pursue this further as I don’t need it that badly.

Categories: linux Tags: , , ,