On Sat, Nov 06, 2010 at 11:34:01AM -0400, Patrick Shanahan wrote:
> When opening/attaching a session in a vnc, tmux complains and fails
> issuing:
> sessions should be nested with care. unset $TMUX to force.
>
> but will start after: unset TMUX
>
> successive xterms also require the unset.
>
On Sat, Nov 06, 2010 at 05:05:31PM -0700, George Nachman wrote:
> > There are three approaches I can see:
> >
> > 1) Protocol changes. This could work, could have a flag to mark this as
> > an "extended" client that gets additional update messages in various
> > places. I'd be concerned how invasiv
$TMUX is set in 1.3.
-- Albert
On Nov 10, 2010 10:16 AM, "Nicholas Marriott"
wrote:
On Sat, Nov 06, 2010 at 11:34:01AM -0400, Patrick Shanahan wrote:
> When opening/attaching a session...
yes. this is correct and expected. you shouldn't attach a tmux session
inside itself or it'll go nuts if yo
As far as history goes it would be possible for tmux to draw the entire
history to a file (or more accurately to a tmux buffer which could then
be saved to a file) as escape sequences for one terminal or another (we
already need an extension of capture-pane to save the history and there
is no reaso
$TMUX will always be set.
And I had a look and the version won't make any difference, I thought it
looked at the pty but it just matches the socket path and that will of
course match (unless you use -L or -S).
On Wed, Nov 10, 2010 at 10:32:03AM -0600, Albert wrote:
>$TMUX is set in 1.3.
>
>
Hi there,
I'm writing to ask that you add XAUTHORITY to the environment variables
being updated by default--without that, X11 connections don't succeed
even with an updated session environment on my Debian box.
Thanks,
Andreas
pgpRF0QqLql7E.pgp
Description: PGP signature
--
i should've said (i guess) that i'm using gcc (don't have a license
for xlc). the problem (imsg_read failed) persists with the latest tmux
version (1.3).
joe
On Tue, Feb 16, 2010 at 3:19 PM, Jozef Riha wrote:
> no, only those two files were created :-(
>
> On Tue, Feb 16, 2010 at 3:15 PM, Nichol
>> Now that I understand your architecture better, it's pretty clear to
>> me that we don't want to write our own client. I want to support the
>> use case of ssh'ing to a remote host and running the tmux client
>> there.
>
> In that case your only options from what I can see are:
>
> a) Open an ss
On Wed, Nov 10, 2010 at 01:41:36PM -0800, George Nachman wrote:
> >> Now that I understand your architecture better, it's pretty clear to
> >> me that we don't want to write our own client. I want to support the
> >> use case of ssh'ing to a remote host and running the tmux client
> >> there.
> >
>
On Wed, Nov 10, 2010 at 4:33 PM, Nicholas Marriott
wrote:
> On Wed, Nov 10, 2010 at 01:41:36PM -0800, George Nachman wrote:
>> >> Now that I understand your architecture better, it's pretty clear to
>> >> me that we don't want to write our own client. I want to support the
>> >> use case of ssh'in
10 matches
Mail list logo
