On Fri, Oct 15, 2010 at 03:34:07PM +0200, marcel partap wrote:
> >you never need to call date because status-left/right are passed through
> >strftime anyway,
> Oh cool, that kinda solves the problem. This does the job for me:
> >set -g status-right "[ #[fg=magenta]#(cat /proc/loadavg | cut -d \" \
> you never need to call date because status-left/right are passed through
> strftime anyway,
Oh cool, that kinda solves the problem. This does the job for me:
> set -g status-right "[ #[fg=magenta]#(cat /proc/loadavg | cut -d \" \" -f
> 1)#[default] ][ #[bold]%X #[fg=blue]%a %x#[default] ]"
With
you never need to call date because status-left/right are passed through
strftime anyway, if you do, tmux will start a new job instead of reusing
the old one because the command changes each time
this will consume a lot of memory over time
On Mon, Oct 11, 2010 at 10:45:30AM +0200, marcel partap
looks like it isn't collecting children, but i can't do much if you
keep being selective in what questions you answer
cutting out bits of ps output is useless because i can't see what the
parent process is
what libevent version are you using?
it is possible that date takes so long on your box th
> is this tmux CVS HEAD?
yes.
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time c
so what was the status-left and status-right?
is this tmux CVS HEAD?
On Fri, Oct 08, 2010 at 12:44:47AM +0200, marcel partap wrote:
> On 07/10/10 23:50, Nicholas Marriott wrote:
> >ps -aelf, top|cat and tmux info
> K ZOMBIES!!
>
> >0 Z empee584 27650 30440 0 80 0 - 0 exit 00:42 ?
On 07/10/10 23:50, Nicholas Marriott wrote:
> ps -aelf, top|cat and tmux info
K ZOMBIES!!
> 0 Z empee584 27650 30440 0 80 0 - 0 exit 00:42 ?00:00:00
> [date]
> 0 Z empee584 27652 30440 0 80 0 - 0 exit 00:42 ?00:00:00
> [date]
> 0 Z empee584 27656 30440
On Thu, Oct 07, 2010 at 10:52:47PM +0200, marcel partap wrote:
> On 07/10/10 22:05, Nicholas Marriott wrote:
> >So with this the problem is that although you do not see a growing
> >number of "true" programs running with ps -aelf, you do see tmux using
> >an increasing amount of memory and CPU in e
On 07/10/10 22:05, Nicholas Marriott wrote:
> So with this the problem is that although you do not see a growing
> number of "true" programs running with ps -aelf, you do see tmux using
> an increasing amount of memory and CPU in eg top?
Naah, no issue whatsoever with #(true) instead command.
So with this the problem is that although you do not see a growing
number of "true" programs running with ps -aelf, you do see tmux using
an increasing amount of memory and CPU in eg top?
On Thu, Oct 07, 2010 at 09:37:22PM +0200, marcel partap wrote:
> On 05/10/10 16:45, Nicholas Marriott wrote:
On 05/10/10 16:45, Nicholas Marriott wrote:
> true still forks a child.
>
> What are you setting status-left and right to again?
set -g status-left "[ #[fg=green]#H #[fg=white]]"
set -g status-right "[ #[fg=magenta]#(true)#[default] ][ #[bold]#(true)
#[fg=blue]#(true)#[default] ]"
--
true still forks a child.
What are you setting status-left and right to again?
On Tue, Oct 05, 2010 at 02:31:28PM +0200, marcel partap wrote:
> On 05/10/10 14:22, Nicholas Marriott wrote:
> >Replace both the #(...) with #(true) in your config, does it still
> >happen?
> No, misbehaviour goes awa
On 05/10/10 14:22, Nicholas Marriott wrote:
> Replace both the #(...) with #(true) in your config, does it still
> happen?
No, misbehaviour goes away if no children are being forked. But well, #(true)
isn't exactly a meaningful status indicator for
anything ;)
---
client has nothing to do with forking children from status-interval,
something is counting the stats wrong
so is this actually causing you a problem?
On Tue, Oct 05, 2010 at 11:06:40AM +0200, marcel partap wrote:
> On 05/10/10 09:09, Nicholas Marriott wrote:
> >How do you mean? Are you saying th
On 05/10/10 09:09, Nicholas Marriott wrote:
> How do you mean? Are you saying the three processes you start once a
> second never exit?
Well at least to my limited understanding, no.. at least with htop or pstree i
can't see any child processes. However, using
dstat --top-io-adv -p
tmux quickly ta
How do you mean? Are you saying the three processes you start once a
second never exit?
Does it happen if you run them once every 30 seconds?
On Mon, Oct 04, 2010 at 10:14:31AM +0200, marcel partap wrote:
> Dear fellow tmuxers,
> as many migrating from the infamous screen, i find the additional
Dear fellow tmuxers,
as many migrating from the infamous screen, i find the additional capabilities of tmux nothing short of amazing. However, the preset
i tinkered together (attached, feel free to add to the examples) seems to exposed a bad problem: each time the status bar is
updated, tmux for
17 matches
Mail list logo
