I have seen this exact issue as well.
If it happens again, is there anything I can do to help debug what the
problem could be?
tmux-1.3 and 1.4.14b-stable
Regards,
Tim
On Thu, July 22, 2010 7:59 am, Richard Morse wrote:
> This is tmux running locally.
>
> Ricky
>
> On Jul 21, 2
On 23/07/2010 1:31 p.m., Nicholas Marriott wrote:
> The last diff was slightly wrong, please test this instead.
Thank you. I will test and let you know if I have any problems.
Tim
--
This SF.net email is sponsored
e epic5 IRC client, resize and reflow the
text straight away, both under screen and tmux.
So I'm curious if this is a tmux issue or a TTYtter issue?
I'm using the latest tmux 1.3, with the patch in Message-ID:
<20100723013107.ga30...@yelena.nicm.ath
Anyone else having issues with vim using the OS X clipboard as it's
default yank buffer? I'm using MacVim as vim and I'm on OS X
10.6.whateveriscurrent. In fact, it doesn't even seem that vim has a "*
register when I run it under tmux.
I have `set clipboard=unnamed` in my .vimrc.
Furthermore
On May 10, 2011 at 08:44 PM +0200, Martial Boniou wrote:
>You need this:
>
>https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
That is indeed what I needed. Thanks. Fixed all my problems I think.
--
Achieve unpreced
I just upgraded my Mac to OS X 10.7. So far I've had two kernel panics,
both times when messing around in tmux. I *think* tmux is the one
causing them, but what do I know :) It could be something else.
When I start the tmux session, I do see the following message:
> warning: unsupported new O
On Jul 22, 2011 at 04:10 AM +0100, Nicholas Marriott wrote:
>If tmux causes a kernel panic it is entirely certain it isn't a tmux
>problem, it is a kernel bug.
I see what you are saying.
>The message you show only really shows it is something to do with the
>VFS but not much else. specfs is basic
On Jul 22, 2011 at 04:42 PM -0500, Chris Johnsen wrote:
>This message comes from the use of the "reattach-to-user-namespace"
>program from
>
>https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
>
>You probably have tmux configured to run the reattach program for each
>new window (e.g. via
On Jul 22, 2011 at 07:50 PM -0400, Tim Gray wrote:
>While I was just able to cause 1 or 2 panics *with* the wrapper enabled
>(but not consistently), I was not able to cause any with it disabled.
>I'll try running like this for a bit and see what I come up with.
Brief followup. At
On Jul 24, 2011 at 02:35 AM +0100, Nicholas Marriott wrote:
>What filesystem are you using for /tmp (or whereever the tmux sockets
>are)?
HFS+, the OS X default.
--
Magic Quadrant for Content-Aware Data Loss Prevention
Re
On Jul 24, 2011 at 03:18 AM +0100, Nicholas Marriott wrote:
>maybe try putting it on a memory FS
>
>do you have anything tmux uses on something other than HFS+?
Not that I know of. I've not done anything at all to the standard OS X
Macbook install. One main partition that everything is on.
I'm
On Jul 29, 2011 at 04:57 PM +0100, Chris Poole wrote:
>> set -g base-index 1
>
>I already have this set; it doesn't work.
For what it's worth, before I started having problems with tmux and OS X
10.7, I was running tmux on 10.6.8 with this option set and it worked...
Wish I tell you something mo
On Jul 29, 2011 at 05:46 PM +0100, Nicholas Marriott wrote:
>are you sure? base-index has never affected pane indexes, just window
Sorry, windows, not panes.
--
Got Input? Slashdot Needs You.
Take our quick survey onlin
ple hasn't fixed things in the last two OS
updates. I'll try again in a couple months :)
On Jul 21, 2011 at 10:35 PM -0400, Tim Gray wrote:
>I just upgraded my Mac to OS X 10.7. So far I've had two kernel panics,
>both times when messing around in tmux. I *think* tmux is the
(apologies for not replying to the original thread; I hadn't subscribed
to the list when I saw the thread scroll by)
On Tuesday 19 Nov 2013 00:03:58 Nicholas Marriott wrote:
> As far as I'm aware konsole is the only one that does this. Possibly
> gnome-terminal, certainly not xterm which is pretty
On Tue, Dec 17, 2013 at 04:35:49AM +0100, Mikhail Morfikov wrote:
> I've been configuring tmux for two days and it works pretty well, but
> there's one thing that causes problems. After I switch to a virtual
> console using ctrl+alt+f2 and enter the tmux mode, I create some panes
> by typing ctrl+a
On Wed, Jan 15, 2014 at 09:28:50PM -0800, Lawrence Jacob Siebert wrote:
> But try as I might, I can't figure out how to do this in tmux. And I love
> tmux, so I'd prefer to use it instead of screen, if at all possible.
tmux always supports 256 colours, but most programs will only try to
display 2
On Mon, Jan 20, 2014 at 04:18:33PM +0100, Andreas Herz wrote:
> I have the bug described in
> http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ
>
> so i created the terminfo screen-it as described in the FAQ.
[...]
> But that destroys LS_COLORS :/
> env | grep LS_COLOR results in LS_COLOR
On Tue, Feb 18, 2014 at 6:36 AM, Marcel Partap wrote:
> Hi,
> please comment on this.
> - sends keyboard UP/DOWN sequences per mouse wheel event
> - active in alternate screen mode (like xterm)
> - also active when pressing SHIFT outside alternate screen (like
> previous iteration)
> - scrolls 3 l
I'm on CentOS 5.8 using a back-ported screen256-color.terminfo that I
snagged from a copy of CentOS 6 using tmux 1.8.
With TERM=screen-256color, my prompt will not wrap long lines.
With TERM={screen,xterm,xterm-256color} my prompt wraps fine.
This is _not_ a tmux issue directly, as if I simply s
On Wed, Feb 19, 2014 at 6:02 PM, Nicholas Marriott
wrote:
> Check what is different between your screen and screen-256color with
> infocmp, there should be very little:
>
> $ infocmp -x screen screen-256color
# infocmp -x screen screen-256color
comparing screen to screen-256color.
comparing b
On Thu, Feb 20, 2014 at 3:25 AM, Nicholas Marriott
wrote:
> What's in your PS1?
# echo $PS1
[\u@\h \W]\$
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Commo
On Thu, Feb 20, 2014 at 3:44 PM, Nicholas Marriott
wrote:
> How long is it and how wide is your terminal when it doesn't wrap? Or do you
> mean it doesn't wrap when you type?
# echo '$copy-of-current-prompt' | wc -c
64
It never wraps. Size of terminal doesn't seem to make any difference.
Small o
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
wrote:
> Did you try modifying a copy of screen terminfo from the running system
> instead of copying it from another? You only really need colors, setaf
> and setab.
How would I go about doing that? All I find on my system are compiled
terminfo
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
wrote:
> Otherwise I suggest you also check the shell startup files (in /etc too)
> to see if there is anything that matches xterm and screen but not
> screen-*.
I did find something here but I'm unclear as to how to interpret it.
In the vanilla
On Fri, Feb 21, 2014 at 3:00 AM, Nicholas Marriott
wrote:
> Easy way to test is to change screen) to screen*) in the file and logout
> and in again but I suspect you are right and it's something else.
Yep. Something else. :)
--
In Christ,
Timmy V.
http://blog.twonegatives.com/
http://five.sen
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
wrote:
> On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
>> On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
>> wrote:
>> > Did you try modifying a copy of screen terminfo from the running system
>>
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
wrote:
> On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
>> On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
>> wrote:
>> > Did you try modifying a copy of screen terminfo from the running system
>>
On Fri, Feb 21, 2014 at 10:33 AM, Nicholas Marriott
wrote:
> You can just copy setaf and setab, the idea is to leave everything except
> them and colors alone
# infocmp -x screen screen-256color
comparing screen to screen-256color.
comparing booleans.
comparing numbers.
colors: 8,
On Sat, Feb 22, 2014 at 12:35 PM, Nicholas Marriott
wrote:
> Hmm. Are you starting a new terminal each time you test or logging in
> and out or what?
Testing procedure is:
1. Edit terminfo
2. tic -x terminfo
3. ntmux test
4. prefix-key 1
5. type a bunch until i get to the right edge of the scree
On Mon, Feb 24, 2014 at 5:56 PM, Nicholas Marriott
wrote:
> So the problem is not that your PS1 doesn't wrap, it's that your typing
> into the shell prompt doesn't wrap.
I'm sorry. I thought that was clear but it clearly wasn't. :)
> Does it wrap if you type into "cat"?
Yes.
--
In Christ,
Ti
On Tue, Feb 25, 2014 at 9:23 AM, Nicholas Marriott
wrote:
> if you run:
>
> eval `resize`
>
> in the shell does it help?
# eval `resize`
bash: resize: command not found
> if not, please run "script" then type at the prompt until it should have
> wrapped and then hit enter, type "exit"
On Tue, Feb 25, 2014 at 9:36 AM, Nicholas Marriott
wrote:
> Can you do the same with a working TERM and show me that typescript file
> too?
Attached.
[root@host ~]# TERM=screen
[root@host ~]# script
Script started, file is typescript
[root@host ~]# staho eustaeho usntaeho usntaeoh usntaeohu snae
On Tue, Feb 25, 2014 at 10:00 AM, Nicholas Marriott
wrote:
> This is confusing, what is " do the same but just type a and so on until
> after it should have wrapped both for working and nonworking.
Attached.
> Also does the first line of "stty -a" match the actual rows an
On Tue, Feb 25, 2014 at 5:25 PM, Nicholas Marriott
wrote:
> What shell are you using? Does this happen in other shells?
I use bash. From my (perhaps wrong) experimentation with it in ksh, it
appears _not_ to happen. If you could give me a recipe for testing it
in a way that would give you informa
ing with a system which is unfortunately stuck
with 1.8.
My end goal is to pipe the output of an interactive program running in the
shell to another program, a logger. Is there a better way to do that? I'm
currently playing around with tee.
On Fri, Jul 11, 2014 at 02:47:09PM +0900, Tatsuo Natsukawa wrote:
> but a tmux resize-pane -t 1 -D 1 gives me:
>
> +---+---+
> | | |
> | 0 | 1 |
> | | |
> | | |
> +---+---+
> | 2 | 3 |
> | | |
> +---+---+
>
> I would like to resize pane 1 without resizing pane 0 with it. Please he
On Thu, Jul 17, 2014 at 04:24:24PM -0400, Kaushal wrote:
> @Michael, thanks for the tip on using `reset`. Now at least I don't need to
> kill the pane every time that happens :)
> @Nicholas, I'll update from git
For more information, see the recently-filed ticket 137:
http://sourceforge.net/p
I have this exact setup working. Maybe share your .tmux.conf?
Mine's here:
https://github.com/timvisher/bash_configuration/blob/master/dotfiles/tmux.conf
On Thu, Jul 17, 2014 at 10:18 PM, Frimann Kjerulf wrote:
> Hi
>
> I'm running iTerm2 on a mac and connecting to various tmux versions on a fe
Hi Everyone,
I use tmux 1.9a on Mac 10.10.2 pretty heavily and I've noticed that
every couple of weeks lately the server simply dies.
I did some research and discovered the `-` flags to spit out logs.
A crash just happened, what do I do to figure out what's going on?
I've captured all the cl
On Thu, Apr 30, 2015 at 07:39:01PM -0500, Elliott Cable wrote:
> So, I can use the mouse to adjust `tmux` panes in Terminals wider than
> 223 characters (I'm not sure *how*, as theoretically the xterm
> sequences should only support indexing up to 223 characters in both X
> and Y *anyway*, if I rec
41 matches
Mail list logo
