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

["Benjamin R. Haskell" <zsh@xxxxxxxxxx>]

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)
} >  SHELL_SESSION_COOKIE=`uuidgen`
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)

Best,
Ben