[ANNOUNCE] screenenv – Physical session environment accessible within screen
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…
Posted at screen-users@gnu.org
Thanks – I was planning to do that when it gets a little more testing, but I suppose it’s just fine this way too! :-)
Hi Pasky,
I think you forgot about the last way of getting environment variables. On UNIX (though not POSIX AFAIK), the main function is declared as:
int main(int argc, char *argv[], char *envp[])
I think this is only an issue for newly started programs which actually care about that third argument, so it should be enough to hijack the execve() syscall…
Anyway, it might be better to do an equivalent of setenv() in each of the processes instead of hijacking library calls. I’ll give it a try and tell you. ;)
@Petr Tesarik
Hi! Thanks for pointing this out, I actually didn’t forget about this, but all of my applications looking at the relevant environment variables use getenv() instead. ;-) But your solution might be more elegant; I guess creating a constructor that calls setenv() should work fine.