Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [ZSH] Re: idea for new feature (was: Re: sticky-note and zle bindings)

On Wed, 11 Jun 2008, Richard Hartmann wrote:

On Wed, Jun 11, 2008 at 02:26, Benjamin R. Haskell <zsh@xxxxxxxxxx> wrote:

I don't see the advantage or difference yet (except the "on a different level" part -- the 'screen' way makes more sense to me at this point).

For example, you can not space out screen windows over terminal emulator tabs. Also, you can not run a screen session across a reboot which works just fine with a ID thing.

Both good points. I hadn't considered the former because terminals, tabs, and I don't get along (47 tabs in Firefox currently, but back when I was using Konsole, tabs just drove me mad.). And the latter because I'd been thinking in the 'screen' paradigm (just saving my running apps, not reinstantiating them or similar).

Perusing the previous thread made me wonder: Is there a solution for the problem of needing co-operation from, say, the X Window manager? Or have you settled on being able to pass in a dead/killed shell's UUID/GUID?

What would you neec X for? The TE sets the variable in the environment and invokes the shell, which takes over from there.

That question was regarding the issues in the second email in the thread you forwarded:

From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
Date: Thu, Jan 17, 2008 at 05:11
To: zsh-users@xxxxxxxxxx


The problem is that zsh can't do it by iself.  So, your X server has crashed and 20 shell windows went kablooie.  Even if every zsh has faithfully been recording its state somewhere, how does each new xterm you launch on the retarted X desktop know which one of the 20 saved states it should restore?

This is actually made *worse* by the fact that many modern X desktops have "session managers" that will remember the apps and placement of your windows and re-launch them on restart, so you may have 20 new xterms all examining the set of state files effectively at once.

Even supposing your session manager doesn't do this, and you have a command to launch a new xterm for every state file and somehow pass it (ZDOTDIR maybe?) the name of the file it should initialize, zsh can't track window placements or much of anything else that would help you to tell which window is which after they reappear.

The upshot is that this isn't a zsh feature -- it's a cooperative feature that requires effort from both the shell and whatever other user interface environment it's running inside.  It's pretty simple to dump state somewhere from the precmd() function, if only you know what to do with it later.


And again in:

From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
Date: Sun, Jan 20, 2008 at 01:05
To: zsh-users@xxxxxxxxxx

On Jan 19, 10:46pm, Andy Spiegl wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
That's the part that would require cooperation from the X session manager and/or the terminal emulator.

But, later emails (that I didn't get to via the web interface) seem to scale that expectation back to the terminal emulator setting a variable or some other scheme (just storing 5,10,... sessions and automatically resuming unless told not to, etc.).

(Is there an alternate interface to the online mailing list archive, btw? I hate all the clicking around -- I'd rather download an .mbox file and use it in Alpine.)

I forwarded you the full thread.

Thanks. Much easier.

Is Alpine a proper replacement for pine, now? I heard of pain when Alpine was born.

I've been using it for months now. But, I never had any trouble. Most of the issues on the lists (alpine-alpha formerly, and alpine-info currently[1]) seem to center around character-set issues (which I avoid by using UTF-8) and differences in pipe behavior (some GPG/PGP scripts can't get the old Pine piping behavior in Alpine).

[1] https://mailman1.u.washington.edu/mailman/listinfo/alpine-info

But, won't this also be a problem with whatever mechanism you're envisioning? Or is this beyond the scope of what you'd want your "thing" to do (re-attaching already-running programs)?

Re-attaching is outside the scope of this. One could think about using a mechanism like retty or simply stopping the execution of the 'child', pivoting STDIN, STDOUT and STDERR from under its feet and letting it run again, but that confuses a _lot_ of programs (for the obvious reason that this is something you normally do not anticipate).

Yes, that makes more sense to me now with more context. (mainly: storing shell state rather than terminal state)


Messages sorted by: Reverse Date, Date, Thread, Author