On Tue, Nov 23, 2010 at 12:24:48PM -0700, James Bowlin wrote: > > I use the PID to link this window information with what is going > on inside the terminal window (tabs and CWDs). This is not > absolutely infallible but it is good enough for me. All the Zsh > shells inside one urxvt window come from the same parent process. > For this step to work it is essential that I don't use the urxvt > client/server. Launching urxvt is plenty fast enough for me so > this is not a problem (for me). The window title links one Zsh > process with the window. I get all the others after finding the > common parent process. Another failing is that the order I > remember is the order of tab/shell creation. So if you move tabs > around I don't remember that. You hit two fences soon in the process. I'm not sure this is a good way to go if you want to avoid headaches.
> I also use the ps command to find the CWD of each Zsh shell of > interest. > It can provide you a listing of the environment of each process and > the CWD is listing in the environment. that's interesting, but here we are going to another point, see below > > Okay, that is half the problem solved, how to remember sessions. > The second half is restoring sessions. This is based on the > ability to select a window's position, size, and desktop via the > command line and on the ability to restore whatever is inside the > window. IMO this is THE point, there are two different things 1) the X properties. That's up to the WM, or any script built around xprop, wmctrl, eesh, ... (In the worse case, at session-close time, use wmctrl windows, store WM_COMMAND and WM_NORMAL_HINTS then, as any X app should support the libX options (x, y, width, height), we can respawn every windows correctly. All WM keep a list of the windows they manage with all the X props we need. And there is always an EWMH way to grab these. 2) The per-app context state. Getting $CWD by the ksh/ps, is a nice trick but it doesn't solve the issue. A real session system should handle more than that. I may want the command line I started to type being also restored + my environment (function, variables, aliases ...) And a non-terminal app may want to store other stuff. So here it's up to the application(s) to provides store() and restore() given, eg, an UID and/or a cache-file path. > E16 provides a command line interface (called eesh, the same one > that produces the list of windows) that allows me to do all I > need once I know the window-id of the window I want to place. > The only way I have to get the window-id is kludgey and fragile. > I get a list of all window-ids before the window in question is > launched then I wait around and poll the entire window list > waiting for something new to show up with the correct name field. So, I agree, there are workarounds but they all have their drawbacks unless you take care to stay away from corner (or use) cases. On the WM side e16 or fluxbox/wmctrl provide all we need On the app side, ksh seems a bit better. But even with the best of both world I still can't see the unix-way-of-managing-session (properly). Of course if it exists somewhere urxvt doesn't implement it, but I think it would be less pain than the indirect means mentioned here. Also note that IF a session mechanism exists inside X, urxvt would in fact ONLY have to restore the shell command line used : - the tab-extension would provide an implementation of store/restore for tab placement, tab name and each shell cmdline - but it would be up to each shell to restore it's context as it was before the session-suspension. The terminal does not really have to know what is running. - if the shell was running, eg, mutt in a custom way (interactively run), then the env and the mutt cmdline would have to be re-run - then mutt would have to restore where it was (mailbox/email opened, line number, ...) Every context hierarchies would be preserved. A large amount of problems would happens with the different mechanism of automatic "on-load*" for each app (mutt may fetch something at startup which it would not be right to do when the session is "just" restored, which part of muttrc should be re-run, which should not ?) ... I'm quite sure there have been some attempts in the ancients times. But until it exists|is rediscovered|is used|is implemented, we have better using the mono-user kernel suspension. For the desktop-manager users, X+GDM/KDM trick works well : hide the root-window and create another one to allow another user to do stuff : If sessions are inherently bound to X, then it not the trick but the solution. If sessions are inherently meant to be cachable on a hard-drive, then it's a little much than a workaround. > If you like Fluxbox ... [snip] > ... less programmable e16. I'm fine with fluxbox > I changed the hotkeys for > moving between urxvt tabs to alt + left/right arrow finger-candy terminal debate: I bound fluxbox tab switch to Alt-a / Alt-z (french layout) to allow me to switch when I'm at phone/drinking/smoking or in case I loose a right-hand (but then I would maybe have to learn Vi) (I don't care about overriding emacs alt-[az] bindings) [And all that stuff is never fixable, I'm quite sure most of my ~/.fluxbox/key will once move to .xbindkeys or .tmux.conf or something else] geeky regards Raphaël _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
