Hi,
A search for 'tmux SSH_AUTH_SOCK' brings up about 8000 pages of hacked
up scripts.
The solution can be simpler if one can just do something like:
$ export SSH_AUTH_SOCK=$(tmux show-environment -t
SSH_AUTH_SOCK)
where '' is some way to refer to current client,
and '-t target-cl
I've attached a new patch. It's the patch you just recently sent with
the following modifications:
1. buffer-limit isn't passed to paste_set. paste_add is the only
paste function that needs it now, and it'll look it up itself.
2. The length and character restrictions for buffer names have been
> Yes I think we could do the same with buffer-limit now it is global too.
Ok, I'll do that.
> I think let's not limit the length or charset of names for now, if someone
> sets it to something silly it'll be a display issue only and their own fault
> anyway.
Ok, I'll remove the restrictions.
>
> Only bit I don't like now is passing return from xstrdup() to xrealloc()
> in cmd_stringify_argv, better just to start len = 1 and x = 0.
I've attached a new patch. The only difference is the implementation
of cmd_stringify_argv, which I've altered to remove what you disliked.
diff --git a/cmd-
Yes you were right to keep passing paste_stack in, I just noticed we could
change that separately :-).
Yes I think we could do the same with buffer-limit now it is global too.
I think let's not limit the length or charset of names for now, if someone sets
it to something silly it'll be a displa
I kept passing in global_buffers since that's what the existing code
did, and I thought there might be a reason (planned future
functionality?), so I kept it. But it makes sense to not pass it in
if you don't expect other paste_stores. But why not do the same with
buffer-limit? paste_add can loo
Here's updated diff.
I renamed the compare funcs and make some other minor tweaks but didn't
change the sticky/unsticky bits.
Why do you limit the buffer names to 16 characters? 16 characters is too
short, but why limit them at all?
Also not certain about limiting them to printables, seems like
Thanks - will look at this soon.
Only bit I don't like now is passing return from xstrdup() to xrealloc()
in cmd_stringify_argv, better just to start len = 1 and x = 0.
On Wed, Apr 23, 2014 at 11:13:32PM -0500, J Raynor wrote:
> I've attached the 2nd part of the "--" patch.
>
>
>
> On Fri,