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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 24,  6:17pm, Robert Knight wrote:
}
} I think the SHELL_SESSION_COOKIE suggestion (perhaps
} SHELL_SESSION_ID?) would be best from my point of view as a Konsole
} developer.  The value should be a unique ID of a known format so that
} terminals don't end up generating pre-existing IDs by mistake.

So in this scheme the terminal emulator creates the SHELL_SESSION_ID
and places it in the environment when the shell is started?  I.e.,
Konsole would be responsible for telling the shell which session to
resume (or to start a new one)?

If that's not what you mean, can you be more specific?

} The only problem with this approach is that there needs to be a way
} for a particular session to be ended.

I'm not sure I follow the nuances here.  If a single window closes
before the user shuts his whole desktop session down, then the session
for that window ends, doesn't it?  Regardless of what application is
the creator of that window?

Is what you mean that the shell needs to find out when it can "garbage
collect" whatever data it has stored for a session that's never going
to be resumed?

} * End a session when an explicit command is sent to it
}   (eg. 'Ctrl+D' or 'exit')

Certainly the shell can clean up when it believes the session is not
going to be resumed.  Even if a terminal emulator later re-uses the
same session ID, the shell will just act as if a new session started.

Of course I may be completely in left field here.

} * Don't end sessions.  Instead keep data around for the last X sessions
}   (where X might be 5,10 or 20).

You'd have to do some kind of time limit rather than a number limit.
I sometimes have more than 20 shell windows open at a time.

} * Define a new escape code to end a session.

What does "escape code" mean here?  What sends it, and to who?

Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
the path to it in the environment.  The shell can then choose to put
its session data in that file, or put it somewhere else and use the
file as a semaphore.  If the emulator (or the desktop session, even)
decides that the shell session has ended, it removes that file.  If
the shell stored its data in the file, the session is gone.  If it
used the file as a semaphore it can garbage-collect any session data
for which the file no longer exists.  (The file would have to be in a
predictable location (SHELL_SESSION_DIR ?) for the latter to work.)