Try this please:
Index: cmd.c
===================================================================
RCS file: /cvs/src/usr.bin/tmux/cmd.c,v
retrieving revision 1.128
diff -u -p -r1.128 cmd.c
--- cmd.c 2 Nov 2016 13:35:36 -0000 1.128
+++ cmd.c 21 Dec 2016 16:34:45 -0000
@@ -418,9 +418,11 @@ cmd_prepare_state_flag(char c, const cha
case CMD_SESSION:
case CMD_SESSION_CANFAIL:
case CMD_SESSION_PREFERUNATTACHED:
+ case CMD_SESSION_WITHPANE:
if (flag == CMD_SESSION_CANFAIL)
targetflags |= CMD_FIND_QUIET;
- if (flag == CMD_SESSION_PREFERUNATTACHED)
+ if (flag == CMD_SESSION_PREFERUNATTACHED ||
+ flag == CMD_SESSION_WITHPANE)
targetflags |= CMD_FIND_PREFER_UNATTACHED;
break;
case CMD_MOVEW_R:
Index: tmux.h
===================================================================
RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
retrieving revision 1.681
diff -u -p -r1.681 tmux.h
--- tmux.h 24 Nov 2016 18:45:45 -0000 1.681
+++ tmux.h 21 Dec 2016 16:34:46 -0000
@@ -1305,7 +1305,7 @@ enum cmd_entry_flag {
CMD_SESSION,
CMD_SESSION_CANFAIL,
CMD_SESSION_PREFERUNATTACHED,
- CMD_SESSION_WITHPANE,
+ CMD_SESSION_WITHPANE, /* implies PREFERUNATTACHED */
CMD_WINDOW,
CMD_WINDOW_CANFAIL,
On Wed, Dec 21, 2016 at 05:14:37PM +0100, Thomas Sattler wrote:
> Hi list,
>
> seems I found a regression: When attaching, tmux does not reliably
> choose the most recently used /unattached/ session anymore.
>
> The following commands show the issue: (run them within 60s)
>
> $ tmux new -d 'echo nobody attaches to me ...; sleep 60'
> $ tmux new -d 'timeout 60 watch tmux ls'
> $ xterm -e tmux a & sleep 1
> $ xterm -e tmux a & sleep 1
> [...]
>
> All xterms attach to the second session, even when it already
> has several clients attached and the first session has none.
>
> Then I compiled and run older (stable) tmux binaries and found:
>
> 2.0 and 2.1 attach like this:
>
> xterm1: session2
> xterm2: session1
> xterm3: session1
> [...]
>
> 2.2 and 2.3 (and git) attach like this:
>
> xterm1: session2
> xterm2: session2
> xterm3: session2
> [...]
>
> All test were done without any tmux.conf's around.
>
> I observed this behavior for quite a while now before I spent
> the time investigate. (Until today I thought it was an error
> in a script I wrote to run tmux remotely via ssh.)
>
> I /think/ it did not happen before I upgraded to 2.3. I may
> be wrong here, or it might be a combination of tmux and its
> libraries:
>
> $ ldd /usr/bin/tmux
> libutil.so.1 => /lib/libutil.so.1 (0xf772e000)
> libncurses.so.6 => /lib/libncurses.so.6 (0xf76d6000)
> libevent-2.0.so.5 => /usr/lib/libevent-2.0.so.5 (0xf768c000)
> libresolv.so.2 => /lib/libresolv.so.2 (0xf7675000)
> libc.so.6 => /lib/libc.so.6 (0xf74c5000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xf74a9000)
> /lib/ld-linux.so.2 (0xf7750000)
>
> Can anyone confirm the issue?
>
> Thomas
>
> --
> You received this message because you are subscribed to the Google Groups
> "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send an email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
