Hi This is a cool idea, tmux should definitely just do the right thing.
We could call realpath() to get around the // issue. If we did it on path in main.c and that would clean up TMUX as well. Is it too early to do it in main.c? I don't think it is necessary to use stat(), a string comparison is fine. On Thu, Feb 04, 2010 at 01:20:13AM -0800, Micah Cowan wrote: > Currently, tmux complains if you create or attach a session within > another tmux session (that is, if $TMUX is set). This is true even if > the new session being created is on a new _server_ being created (e.g., > "tmux -L new"). > > This patch addresses this issue by silently succeeding when the new > session is on a new server. The relevant check has been moved from the > server to the client, which complains only after it has successfully > connected to a preexisting server, _and_ determined that server to be > the same one named by $TMUX (that is, the same one in which we're > already running). > > The $TMUX == socket path comparison is a string comparison, so it may > now allow you to connect to what is actually still the same server. > Especially when you consider that, at least on a Linux system, default > $TMUX is "/tmp//tmux-XXXX/default", so even just "tmux -S > /tmp/tmux-XXXX/default" would be permitted to nest. > > If you don't like that, you could just strip the $TMUX == socket path > comparison from client.c, leaving it as just a "is the server a > preexisting one, or a new one (and is $TMUX set)?" check, by replacing > the body of the outer "if" by the one in the inner "if". It's a choice > between being a little too permissive, and a little too restrictive (but > not as restrictive as it currently is). > > Of course, a more precise approach would be to stat() the $TMUX path and > the connected socket, and compare to see if they're the same file. > > Word of advice: I recommend that you stop _all_ running tmux servers > before testing this. Otherwise it's just too easy to confuse yourself. > Is the error message coming from the client, or the server? Unless you > are absolutely certain that no pre-patch server is running, things can > get complicated. > > Or maybe it was just complicated for me because it's getting late... but > I screwed myself up by all of (1) accidentally using the older client > (2) accidentally using the new client on the older server when nesting > (and thus getting the unconditional no-nest message from the server), > (3) accidentally using an alias which I'd forgotten sets TMUX= to > explicitly allow nesting no matter what. :p > > -- > Micah J. Cowan > http://micah.cowan.name/ > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
