I've attached a new patch for the logging.
> - Don't add new calls to status_replace please. Use format API directly
> instead.
The new patch does this.
> - These option names aren't great. How about automatic-log and
> automatic-log-format (or automatic-log-file)?
Yeah, I didn't care for
Hi
Only had time for a quick look but a few things:
- Don't add new calls to status_replace please. Use format API directly
instead.
- These option names aren't great. How about automatic-log and
automatic-log-format (or automatic-log-file)?
- The hunk in cmd_set_option_exec is ridiculously
I've attached a new patch that implements logging without adding a new
command and without touching pipe-pane.
There's a window option called logging-default-logname that's set to
"~/tmux-#S-#I-#P.log" by default. That's what name logfiles will get
when they get created. I mainly needed a string
On Sun, Aug 18, 2013 at 1:42 AM, Nicholas Marriott
wrote:
> I think either you or me are miss the point :-).
Oh, I'll bet it's me.
> There is no point adding something to pipe-pane or something that does the
> same as pipe-pane. People who want to log individual panes can already do it
> with p
d be separate from pipe-pane
so you can use the two independently.
Original message
From: J Raynor
Date: 18/08/2013 04:41 (GMT+00:00)
To: Nicholas Marriott
Cc: tmux-users@lists.sourceforge.net
Subject: Re: patch allowing pipe-pane to write directly to a file
Combinin
Combining the logging with pipe-pane seemed to be the easier option
since I'm familiar with both bits of code, so I gave that a shot and
I've attached a new patch.
The code for the logging and for having pipe-pane write to a file are
a bit simpler than previous patches. There's no need for a sepa
On Sat, Aug 17, 2013 at 03:46:56PM -0500, J Raynor wrote:
> On Sat, Aug 17, 2013 at 3:50 AM, Nicholas Marriott
> wrote:
> > Do we need a new command? Why not just a window option log-file and if it is
> > set all panes in that window are logged? People who want everything logged
> > can set it glo
On Sat, Aug 17, 2013 at 3:50 AM, Nicholas Marriott
wrote:
> Do we need a new command? Why not just a window option log-file and if it is
> set all panes in that window are logged? People who want everything logged
> can set it globally. If we have a new command it is hardly different from
> pipe-p
> Why are you using status_replace() for this? format_expand() and
> using a struct format_tree * makes much more sense here. What has
> status_replace() got to do with expanding file names?
I want to allow things like #S and #P in the filename so people can
tell the different logs apart. Using
: 17/08/2013 03:41 (GMT+00:00)
To: Nicholas Marriott
Cc: tmux-users@lists.sourceforge.net
Subject: Re: patch allowing pipe-pane to write directly to a file
I've attached a patch that implements logging with a new command,
log-pane or logp. A -b flag will begin logging for the pane, -e
Hi,
If I get time over the weekend I'll look in to this in more detail,
but just going by what you've put here...
On 17 August 2013 03:41, J Raynor wrote:
> In order to allow things like #S and #P in the filename I had to alter
> status_replace(). That function required a non-NULL client variab
I've attached a patch that implements logging with a new command,
log-pane or logp. A -b flag will begin logging for the pane, -e will
end it, and -o will toggle it on/off, similar to pipe-pane. You can
specify the filename with -f, but if you don't, there's a default
that's set to "~/tmux-#S-#I-
Ok well if it is lightweight it might be nice to have, thanks.
On Wed, Jul 31, 2013 at 08:06:39PM -0500, J Raynor wrote:
> > Entirely separate process that could fork a "tmux -C attach", it
> > wouldn't even need to be C.
>
> Ah, now I understand what you meant. That's quite different from what
> Entirely separate process that could fork a "tmux -C attach", it
> wouldn't even need to be C.
Ah, now I understand what you meant. That's quite different from what
I had in mind.
The desire to log sessions can't be that strange. Different terminal
emulators, like putty, iTerm, and KDE's kons
Entirely separate process that could fork a "tmux -C attach", it
wouldn't even need to be C.
Whether that would suit your requirements or not I don't know.
On Wed, Jul 31, 2013 at 05:38:55PM -0500, J Raynor wrote:
> > You could possibly record it externally by starting a control client
> > for e
> You could possibly record it externally by starting a control client
> for each session and listening for %output.
By "externally" do you mean a separate process? Or just a separate
bufferevent processor (external to the pane), so that each pane isn't
doing its own file writing?
--
You could possibly record it externally by starting a control client
for each session and listening for %output.
On Tue, Jul 30, 2013 at 05:49:20PM -0500, J Raynor wrote:
> Ok. Maybe I'll take a stab at adding an actual logging facility and
> see if that might be more palatable.
--
Ok. Maybe I'll take a stab at adding an actual logging facility and
see if that might be more palatable.
--
Get your SQL database under version control now!
Version control is standard for application code, but databases
00:00)
To: tmux-users@lists.sourceforge.net
Subject: patch allowing pipe-pane to write directly to a file
I use pipe-pane to capture the output of my sessions, but I would
prefer not to have to spawn external processes to do so. I've
attached a patch that enables pipe-pane to write direct
I've attached a new patch. The functionality now uses socketpair
instead of bufferevent_pair_new(), so it'll work with libevent1 and 2,
and there's no need to reimplement any of libevent2 in tmux.
pipe2file.patch
Description: Binary data
--
> If you log lots of sessions, what the hell are you doing in the first place
> that needs it? You could always use script(1) or ttyrec(1) instead.
I prefer to log my sessions so that I have a history in case I need
it. And occasionally I do. I know I could use other tools, but if
that's what s
I wasn't trying to make the claim that using cat hurts performance,
just that it uses more resources than is necessary.
With libevent1, all other functionality should still work. You just
wouldn't get the write-to-file functionality.
It looks like libevent1 was last updated over 3 years ago. Wo
On Sat, Jul 27, 2013 at 04:13:13PM -0500, J Raynor wrote:
> I use pipe-pane to capture the output of my sessions, but I would
> prefer not to have to spawn external processes to do so. I've
> attached a patch that enables pipe-pane to write directly to a file.
> I realize the semantics are a littl
On Sat, Jul 27, 2013 at 05:43:52PM -0500, J Raynor wrote:
> >
> > Why? What's wrong with using cat?
> >
>
> I log my sessions, so I end up with a bunch of cat and sh processes,
> and it just bugs me slightly seeing them when they don't need to be.
Well, they're a means to an end. That's no worse
>
> Why? What's wrong with using cat?
>
I log my sessions, so I end up with a bunch of cat and sh processes,
and it just bugs me slightly seeing them when they don't need to be.
Some better reasons for it would be:
- If you log lots of sessions, you're getting closer to hitting maxuproc.
- Usi
Hi
Why? What's wrong with using cat?
On Sat, Jul 27, 2013 at 04:13:13PM -0500, J Raynor wrote:
> I use pipe-pane to capture the output of my sessions, but I would
> prefer not to have to spawn external processes to do so. I've
> attached a patch that enables pipe-pane to write directly to a fi
I use pipe-pane to capture the output of my sessions, but I would
prefer not to have to spawn external processes to do so. I've
attached a patch that enables pipe-pane to write directly to a file.
I realize the semantics are a little off; you pipe to processes, not
files. But it's close.
Doing
27 matches
Mail list logo
