Hi
Why do you need to make sure it exists? Why not create it?
If you want to change the code there are a couple of possibilities:
- Make sure everywhere we dereference curw is safe if it is NULL, ie
anywhere we assume a session has at least one window (the current
window). This should be fairly easy to achieve in the path through the
server loop (just keep fixing until it stops crashing) but making
everywhere else safe might be a bit of a mission. You will also need
some logic to make redrawing work but that's probably just a matter of
some special cases in server-client.c and screen-redraw.c to draw
blanks (maybe have a blank struct screen in the session for the
purpose).
- Make an empty window with one dead pane (it doesn't need a pty, dead
panes with fd = -1 are already handled) to be the only window in empty
sessions. You'll need one for each session because they can be
different sizes. This would require a bunch of checks to prevent the
user splitting, killing or moving or otherwise doing things with this
window and to make it go away when a new window comes along.
I'm not entirely sold on the idea of doing this at all, but if you can
convince me it's needed then I think the first solution is the better -
empty sessions should actually be empty.
There may be other options if you explain why you need empty sessions -
if you are worried about atomicity on creation then extending the way
command sequences work to allow conditionals has been on the todo list
for a while.
On Sun, Mar 24, 2013 at 06:46:36PM +0100, Jens Stimpfle wrote:
> I'm currently working on a shell script package for remote
> administration, involving tmux [1]. A script called tmux-job moves
> windows to another session after the contained job has finished (based
> on exit code). It must make sure that the target session exists. To
> avoid hacking, it would be very practical if there were persistent
> sessions (sessions which are not destroyed when the last window has
> gone).
>
> I've already digged into the code, but simply not destroying the session
> results in server crashes (as expected). Proper patching probably
> requires proficiency with the RB tree macros and more.
>
> Is it possible to implement persistent sessions? I can't really estimate
> how complex this is. At least, it involves adding an option (set
> destroy-empty [on | off]) and something like a dummy pty ("(empty
> session)") with no job running inside for empty sessions.
>
> If nobody is interested, but somebody can give me a rough sketch on
> where the important places in the code are, I don't mind having another
> try myself.
>
>
> Have a nice day
> Jens Stimpfle
>
>
> [1] Advertisement: https://github.com/jstimpfle/adminscripts
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
