Below is a patch for getting tmux running on cygwin. I only have access to
a 32 bit XP system, so I don't know if it works on other versions of
Windows. Cygwin doesn't provide a libevent package, so you'll first have
to install that. I used libevent-2.0.21-stable. Also, for tmux I had to
The patch I had sent in was meant for testing, and to see if there was
any interest, so I wasn't putting any effort into getting it into
shape for acceptance. Now that that might be possible, I'll get it
cleaned up, taking into account your notes.
I guess this obviously won't let other things
I've attached a new patch.
TTY_NAME_MAX is already defined in compat.h, so I didn't need to add
it. Gcc didn't define _WIN32, so I used __CYGWIN__ instead.
Regarding this:
You should probably fail early if isatty is false (before filling in ttyname
into the identify struct).
I believe
I've attached an updated patch.
You had wanted the change to resolv.h to go into compat.h, but I
didn't see how to do that since I needed to comment it out. But I
figured out that I just needed to undef something. I put that in
compat.h, so now tty.c isn't changed at all.
tmux-cygwin.patch
I've attached a new patch that puts the msg_identify_data change in an
ifdef. Also, in compat.h, I moved the undef b64_ntop for cygwin
into the ifndef HAVE_B64_NTOP check so that if cygwin ever gets a
working b64_ntop tmux will continue to compile.
If I do tmux new /dev/null then tmux doesn't
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
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.
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
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
The TODO list for tmux has this entry:
* add -c for new-session like new-window
I've attached a patch that implements that.
new-c.patch
Description: Binary data
--
Get your SQL database under version control now!
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
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?
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
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
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
On Sat, Aug 17, 2013 at 3:50 AM, Nicholas Marriott
nicholas.marri...@gmail.com 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
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
On Sun, Aug 18, 2013 at 1:42 AM, Nicholas Marriott
nicholas.marri...@gmail.com 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
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
There are some conditions I don't know how to generate, so I couldn't
test those. But I tried testing what I could, and it appears that
this preserves the behavior of neww and split-window, and that the
prefixes for new -c match the -c behavior for neww and split-window.
Does cmd_default_path1
This looks fine too, except it looks like the unreachable return
(base); is still there.
Also, the comment above cmd_default_path() mentions using the
default-path option, but that's now taken care of elsewhere. So that
might need an update.
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
Could you try pulling the latest from git and compiling it? Once
compiled, if it still doesn't work, what happens if you do:
tmux /dev/null
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
If you run it normally, does it work now?
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get
Mark was starting cygwin using the cygwin.bat script. This results in
a terminal with /dev/cons0 (or cons1, cons2, etc) instead of /dev/ptyX
as the tty. From the cygwin documentation:
Starting with Cygwin 1.7.10, Console sessions are numbered from /dev/cons0
upwards.
Console device names are
I've attached a patch that implements this.
tmux-otherend.patch
Description: Binary data
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for
It looks like there's a bug in the window_copy_scroll_up and down
functions where they don't correctly highlight what's been selected
for copying.
To see the problem with window_copy_scroll_up, do the following:
1. Generate more than a screenful of text.
2. Enter copy mode.
3. Scroll up some
I applied your patch and it corrects the problem.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn
I've attached a patch that implements case insensitive searching in
copy mode. The case insensitive searching only works for ascii
characters (not unicode) because that's all tmux appears to allow you
to enter when you do a search.
The patch adds a new window option called
How about doing this the emacs way? All lowercase means case-insensitive,
any caps means case-sensitive.
Sure. I've attached a new patch that does that. There's no window
option this time since it isn't needed.
tmux-case-insensitive-search.patch
Description: Binary data
Can't you just use cmd_find_pane? If the user doesn't specify a pane
it'll default to the active pane anyway so selecting it'll be a no-op.
Do you mean use a patch like this:
diff --git a/cmd-attach-session.c b/cmd-attach-session.c
index e4c0b23..7f7153e 100644
--- a/cmd-attach-session.c
+++
Can't you just use cmd_find_pane? If the user doesn't specify a pane
it'll default to the active pane anyway so selecting it'll be a no-op.
Your suggestion got me to look at my patch again, and I think it
could've been clearer. I've attached an updated patch. Everything
should behave the same
This works fine. However, as of 1.8, it is possible to have a period
in the session name and to attach to it. With this patch, it's no
longer possible to attach to such a session since the period is
interpreted as a pane specifier. Does that matter?
The tmux TODO list has this item regarding command sequences:
* don't require space after ;
I've attached a patch that does this.
diff --git a/cmd-list.c b/cmd-list.c
index 08e2067..22327cd 100644
--- a/cmd-list.c
+++ b/cmd-list.c
@@ -29,55 +29,85 @@ cmd_list_parse(int argc, char **argv, const
There's this item on the tmux TODO list:
* way to set socket path from config file
I was thinking of trying to implement it, but I thought it needed
discussion first.
I was thinking that there could be a command, like set-client or
set-flag. This could be used to set the socket path
I don't really see a need for this at all, especially given the
complexity it'll add to the client
Do you not see a need for the TODO list item (anymore), or just the
proposed implementation?
If it's the latter, how about something simpler? The client could
read the config file and look for:
Ok. I'll drop it.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a
I've attached a patch which implements this. The 't' group of escape
sequences are described as being for window manipulation in some
documentation, so that's why I picked WMN in the INPUT_CSI_WMN
identifier.
diff --git a/input.c b/input.c
index 259fad1..e27ecbb 100644
--- a/input.c
+++ b/input.c
Sorry, after I submitted the patch I realized it was incorrect.
Certain options take arguments and my patch didn't account for that.
I've attached a new patch which does.
On Wed, Jan 29, 2014 at 12:28 AM, J Raynor jxray...@gmail.com wrote:
I've attached a patch which implements this. The 't
How about WINOPS instead of WMN? This matches xterm src and seems a bit
more readable. Otherwise looks good.
Sure. I've attached an updated patch with WINOPS instead of WMN.
diff --git a/input.c b/input.c
index 259fad1..bc4f912 100644
--- a/input.c
+++ b/input.c
@@ -154,6 +154,7 @@ enum
Take a look at this instead which a) uses a function like CSI, SM etc b)
don't increment m inside function arguments.
This works fine. However, I noticed that just incrementing m may
cause it to skip over bad input. For example, a winop of 3 is
supposed to take 2 arguments. If someone enters
Please don't use expressions with side-effects like m++ in function
arguments, it's too easy to miss.
Ok. I've attached a new patch that meets your request.
diff --git a/input.c b/input.c
index 259fad1..23804b9 100644
--- a/input.c
+++ b/input.c
@@ -74,6 +74,7 @@ void
This breaks quotes, for example try:
neww -n a;neww
I knew the patch caused this behavior.
I know the existing code allows things like 'neww -n a; neww'
And that's why I didn't think it was a problem. I figured it was
established behavior that semicolons weren't safe in quotes. People
The tmux TODO list has this item:
* use -- to mark start of command w/ neww etc to avoid quoting
I'm a little confused about this, so I'm hoping to get some
clarification. In this email:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5432
...the user gets a usage error
I don't think you need to modify getopt, the commands just need to handle a
variable number of args but I don't remember specifics of what needs to
change.
I still don't see how I can get -- passed to neww. For example,
this works fine in tmux 1.8:
tmux neww -- emacs
There's no code in
No, this is why -- exists, and on BSD, getopt() does not do --
scanning, unlike on Linux.
The man page for getopt in openbsd mentions checking for --, and
tmux's compat/getopt.c, which has a lot of BSD in it, also checks
for --.
would never see it, and so couldn't alter its behavior.
Neww doesn't need to get -- it just needs to know how many args it has. The
-- is to make getopt pass args to neww rather than treating as flags eg
tmux neww -x -- foo -y
Needs to set x flag in args but pass 2 args to neww foo and -y.
I believe the existing code already does this. Neww
The original behaviour needs to stay if there is 1 arg.
Should there be a way to force the new behavior? This might be
desirable since quoting would be different in this one case. For
example, someone might enter:
neww /path/x y/bin/foo
...and their intention is to run the command foo that
I've attached a patch that allows people to specify a command to neww
and related commands without having to quote the command. Using --
is only needed if the command you want to run happens to start with a
dash.
tmux-dashdash.patch
Description: Binary data
- If we are going to call execvp we should control PATH, I think we
should probably get it from the client if it's a command line client
else from the session environ. In any case you'll need to pass it in
from the caller as yet another argument.
Tmux currently runs commands by calling
I reckon we always set PATH and yes pass it into the func. Behaviour will
only change if someone sets PATH in global or session environment
themselves.
I've attached a new patch with the new PATH behavior, and the patch
also fixes the 2 issues you noted with cmd_stringify_argv.
It looks like there's a potential memory leak in
window_copy_copy_selection. This function calls
window_copy_copy_buffer, which calls paste_replace. If paste_replace
succeeds, it stores the data that was passed to it.
But if paste_replace fails, such as when an invalid buffer index is
Why not this instead? Also fix some other similar problems.
I was hesitant to free the memory in window_copy_copy_buffer in case
the caller wasn't done with it. But since all current callers are
done with it, I guess it doesn't matter.
Your patch looks good.
I suppose paste_replace could always handle the freeing of the memory.
This would preserve its fire and forget nature.
See the attached patch.
tmux-ml.patch
Description: Binary data
--
Android apps run on BlackBerry 10
In the copy/paste improvements section of the TODO list there's this item:
* append to buffer
I've attached a patch that implements this. I've added a new command
called append-buffer, which works like set-buffer. I added the code
for this in cmd-set-buffer.c to avoid adding a new source
Hi. Can you make this a flag to setb (-A? -a?) instead of a new command?
Sure. I've attached a new patch. There's no append-buffer command,
and passing -a to set-buffer will cause it to append.
tmux-append.patch
Description: Binary data
This looks good but you need to add the new flag and key to the manpage?
I've attached a new patch that includes updates to the man page.
tmux-append.patch
Description: Binary data
--
Managing the Performance of
Applied with a few changes, thanks
The changes removed a bit of functionality. If someone does setb -a
foo, then I believe that foo should get appended to what's at
buffer 0, assuming it isn't NULL. That doesn't happen with the patch
that got applied.
If the removal of that functionality was
The TODO list has this item:
* get_cwd for cgywin
I've attached a patch which implements this, along with get_name.
Cygwin's /proc filesystem is similar enough to linux's that the code
could be copied from osdep-linux.c, and that's what I've done.
osdep-cygwin.c is just a copy of osdep-linux.c,
nice, i thought they would probably be very similar but the guy who
requested this said he tried to copy osdep-linux.c and it didn't work
Hmm. Did he supply a patch? I'm just wondering if he forgot to
update configure.ac. In that case, tmux would've continued to use
osdep-unknown.c.
I did not submit a patch because I could not get `tmux splitw -c
'#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
patch submitted by J Raynor worked for me though, but I'm still always
getting new panes/windows opening at `~`. I git-pulled the latest master
I did not submit a patch because I could not get `tmux splitw -c
'#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
patch submitted by J Raynor worked for me though, but I'm still always
getting new panes/windows opening at `~`. I git-pulled the latest master
It looks like cygwin's /etc/profile is causing the homedir behavior.
Add this line to your tmux.conf and the behavior should stop:
set-environment -g CHERE_INVOKING 1
--
Learn Graph Databases - Download FREE O'Reilly
I've attached a patch that just does the PATH bits.
diff --git a/cmd-new-session.c b/cmd-new-session.c
index 15e411d..8953820 100644
--- a/cmd-new-session.c
+++ b/cmd-new-session.c
@@ -54,11 +54,12 @@ cmd_new_session_exec(struct cmd *self, struct cmd_q *cmdq)
struct window *w;
struct environ
The following will cause a fatal error in recent tmux code:
setb
The empty string leads to an xrealloc in cmd-set-buffer.c with a size
of 0, which is fatal. I've attached a patch which fixes this.
diff --git a/cmd-set-buffer.c b/cmd-set-buffer.c
index 0e754bb..e7f9b95 100644
---
For cygwin, you may also need to set/export CHERE_INVOKING=1 before
starting tmux, or put this in your .tmux.conf:
set-environment -g CHERE_INVOKING 1
See here for more:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5920
I've attached a patch which implements named buffers.
Commands that take a buffer arg, like save-buffer and paste-buffer,
have been modified so that -b can take a number or a name. So, you
can do setb -b myBuf someData.
buffer-limit applies to both the paste stack and the named buffers.
So if
parts of the patch need to modify some of the
same lines in different ways, so they'd conflict if they were just 2
unrelated patches.
On Tue, Mar 11, 2014 at 7:05 PM, J Raynor jxray...@gmail.com wrote:
I've attached a patch that just does the PATH bits
In cmd-new-session.c, you've made path's type char *, but everywhere
else it is const char *. Was that intentional?
The parts of your patch that take the path from the global or session
env seem redundant, unless I'm missing a use case. When a new
session, window, or pane is created, a new env
On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Applied this to OpenBSD now with the const char * thing fixed. Thanks
Ok. I'll wait until this shows up in the git repository and then send
in the 2nd part of the -- patch.
Your proposed implementation looks fine to me. I have a question about this:
- buffer-limit is only applied to !sticky buffers
Which of these did you mean?
1. Buffer-limit limits the total number of buffers (the sum of sticky
and non-sticky), but only non-sticky buffers get aged away.
2.
I've attached a new patch for named buffers. There's no longer a
paste stack. There's a name-tree which stores all the buffers, and a
time-tree which just stores unsticky buffers. The time-tree only
needs to store unsticky buffers since they're the only ones which can
be aged away.
I was going
I've attached the 2nd part of the -- patch.
On Fri, Apr 18, 2014 at 12:39 PM, J Raynor jxray...@gmail.com wrote:
On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Applied this to OpenBSD now with the const char * thing fixed. Thanks
Ok. I'll wait until
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
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
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.
Did
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
Sorry, I made an off-by-one error in cmd_stringify_argv. I've
attached a new patch.
On Thu, Apr 24, 2014 at 5:42 PM, J Raynor jxray...@gmail.com wrote:
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
at 10:55:49PM -0500, J Raynor wrote:
I've attached a patch which implements xterm's title stack
functionality for screens inside tmux.
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run
My patch isn't correct. It misses the case where there's only 1 item
in find_list.
I've attached a new patch which should correctly free the memory.
On Thu, May 1, 2014 at 1:48 AM, J Raynor jxray...@gmail.com wrote:
It looks like there's a memory leak in cmd_find_window_exec. This
function
I've attached a patch that just updates the man page. If this patch
is acceptable, let me know if you would like this combined with the
patch for the code into a single patch.
On Thu, May 8, 2014 at 2:41 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
This looks good, it needs to go in
Do you mean order everything by time when displaying the buffers in
buffer-list and buffer-choose? Or do you mean order everything by
time in all cases, so that paste_get_top refers to the most recent
buffer, even if it is !automatic?
If it's the former, that sounds fine. If it's the latter,
Only need to change paste_cmp_times, paste_(get|free)_top and remove the
RB_INSERT and REMOVE from paste_rename:
I think paste_set needs to be modified as well. When it replaces a
buffer, it frees the old one and mallocs a new one. The new one needs
to have pb-order set to paste_next_order++.
When you installed tmux via cygwin, you might’ve updated some other packages
that brought new behavior. I have to do some more checking, but it looks like
cygwin might have changed something recently so that it doesn’t set errno when
it can’t connect to an existing socket file, and this
pane_current_path on solaris doesn't work. I only have access to
solaris 11, so I can't tell if this is a new problem with that version
or if it hasn't worked for a while.
I've attached a patch that fixes the problem, but I can't test on
previous versions of solaris.
In osdep-sunos.c,
Tmux is hanging on aix, and the problem appears to be a race condition
in the implementation of forkpty.
Aix has the behavior that, if data has been written to the slave side
of a pty but has not been read yet by the master side, then the last
close of the slave pty will hang until the data is
I think you should probably loop for EINTR from read() but otherwise
this looks fine to me.
I've attached an updated patch.
diff --git a/compat/forkpty-aix.c b/compat/forkpty-aix.c
index db9c2e7..98119f0 100644
--- a/compat/forkpty-aix.c
+++ b/compat/forkpty-aix.c
@@ -23,16 +23,20 @@
#include
The patch compiles, but part of the change you made reintroduces the
race condition. The parent process has to close the slave before
closing the write pipe.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog
I’m not seeing a hang, but I do see a defunct process. It appears to
be due to a race condition.
Tmux startup is a little slow on cygwin, which I think is what’s
triggering the race condition. It looks like tmux ends up setting
client_attached=1 before the child process in daemon() exits. As a
I'm not seeing the problem on OS X. Did you build tmux yourself, or
did you install it via macports, homebrew, or fink?
Check your .profile (or .bash_profile) and see if you've got a cd
command in there.
On Sun, Oct 19, 2014 at 7:10 PM, Mark Volkmann
r.mark.volkm...@gmail.com wrote:
On Oct
Thecolour_fromstring function intends to accept string values “90" through “97", but doesn’t because it checks incorrectly.Here’s how it checks “91”: if (strcasecmp(s, "brightred") == 0 || (s[0] == '9' s[1] == '1' s[1] == '\0')) return (91);Notice it checks s[1] twice, instead of checking
schrieb J Raynor:
Also, when you set the background color with this patch,
it changes the background for the whole pane, and not
just for the parts of the pane that have text on them
This seems not to be true when using colors like #c0c0c0
(I tested with latest tmux-git with tmux
But might make tmux flicker quite a bit over SSH or on slower terminals.
I don't think it'll cause flicker. Tmux tries to limit how much needs
to be written to the terminal. I did a quick login test with trickle,
setting upload/download speeds to 1K, 2K, 8K, and 16K. I don't see
any
I've attached a new patch. There are 2 new window options,
window-style and window-active-style, that allow you to set the
window's color and the window's active pane color. The display-panes
command can still be used to set an explicit pane color with -P.
tty_attributes now takes a window pane
I checked back over the emails for my patch, but I don't see any
mention of mouse events. Was there a discussion off list? If so,
I'll need to know what else you've found wrong. I can't fix it if I
don't know about it.
It's _still_ missing a fix in server-client. See the following:
diff
Right now, if you try to set a style with a bad value, tmux will
return an error, but it'll set the style to default. This happens
even if the style isn't currently set.
For example:
localhost tmux show -w
localhost tmux set pane-border-style bg=BadValue
bad style: bg=BadValue
localhost tmux
I've attached a new patch. This patch:
* Adds Thomas's fix for pane selection via the mouse
* Gets rid of nflags in cmd_display_panes_exec
* Fixes the usage of memcpy in window.c
* Leaves tty_reset unchanged
* Has the tty_cmd_* functions call tty_attributes instead of tty_reset
* Includes
- I don't think you need to allocate the gc with malloc, just put it
inside the wp directly and initialize it to grid_default_cell.
I do need to allocate it with malloc. If I don't, it's always there
(not NULL), so it'll always have some value. That makes it impossible
to tell what to do
I’ve attached a patch that allows you to set the foreground and
background color for a pane. The way it works is that, when tmux
writes to the screen, if it would have written with the terminal’s
default color, but you’ve set the pane’s default color option, then
it’ll use that color instead.
This will not work as it is on terminals which do not support BCE. To
make it do so you will pretty much have to make tmux support BCE :-).
Ok, it now works on systems that don't support BCE. I've attached a new patch.
diff --git a/cmd-display-panes.c b/cmd-display-panes.c
index
1 - 100 of 113 matches
Mail list logo
