Hi everybody,
In tmux copy-mode (Emacs), I am able to use Alt-R to move the cursor to the middle of screen. Is it possible to move the cursor to the beginning and end of screen? (similar to M-r in Emacs defined by function move-to-window-line-top-bottom in window.el)

Thank you very much!
Bests,
Khon

I am working with a development board that occasionally spews junk characters to the terminal. On occasion I've noticed that this hangs my tmux and screen windows. I isolated one sequence that does this consistently; the test case is:

echo -ne "\ek"

Basically the issue is that the state machine in input.c thinks that we're trying to rename the current window, so it collects input characters until it sees "\e\". If the "\ek" came from another source, it is unlikely that "\e\" will ever arrive.

Characters typed while the window is "hung" will still be passed to the terminal, but the terminal's responses won't be displayed.

Usually a lone "\e" character is enough to get tmux out of this state, so typing something like this will work:

echo -ne "\ek"
echo -ne "\e"

The second command won't be echoed to the terminal, but it will take effect.

Also, having ANSI sequences or colors in your $PS1 prompt could mitigate the problem.

I'm not sure on the best way to handle these sorts of sequences in tmux. Some possibilities include:

• Implement a timeout that ends an ANSI escape sequence.
• Implement a max character count. e.g. if tmux sees 100+ characters entered for the window title, it's probably not a valid window title.
• Allow unexpected characters, such as '\n', to abort the rename sequence.

More of a feature request. It would be great if I'm using mouse, and can click on the tab name (e.g. on "2:bash") it opens up that tab if a different tab is opened right now.

Tmux is by far the tool I use most in my daily development and has revolutionized my workflow. Thanks for starting something that has benefited millions of developers across the globe.

Feel free to close this now

if TERM environment variable is different from xterm* or rxvt* the variable pane_title does not get updated. Default TERM value inside tmux is screen or screen-256color.

#{pane_title} should be updated at least whith TERM=screen or TERM=screen-256color (not necessarily with any other values, but at least the values tmux works well with).

I would like to be able to see the jobs that I have running in the background in the status bar.

Here is what I tried :

set -g status-right '#[fg=black,bright]#(jobs | wc -l)'

However, this will not show anything because I guess the jobs command is not called from the context of the current pane but rather an other unacessible tty.

Is they a way to run the jobs command from inside the tty of the current pane ?

I guess this is rather new functionality, but I couldn't find very specific information in the manpage about exactly what is supported by the -P flag. It seems like I can send it default, colors for bg and fg, but I don't know what else I can do. I was sort of hoping that maybe I can control border colors for specific panes, but that does not appear to be the case.

I tried to do something in all panes of all windows of all sessions in tmux:

for session in `tmux list-sessions -F '#{session_id}'`; do
  for window in `tmux list-windows -t $session -F '#{window_id}'`; do
    for pane in `tmux list-panes -t $window -F '#{pane_id}'`; do
      echo $session $window $pane
    done
  done
done

list-sessions and list-windows works but list-panes doesn't. Let's say I have the following setup:

• session $0
  • window @0
    • pane %0
• session $1
  • window @1
    • pane %1
  • window @2
    • pane %2
    • pane %3

When I execute the script above in pane %0, the result depends on whether window @1 or @2 is active in session $1.

window @1 is active in session $1:
$0 @0 %0
$1 @1 %1
$1 @2 %1

window @2 is active in session $1:
$0 @0 %0
$1 @1 %2
$1 @1 %3
$1 @2 %2
$1 @2 %3

So: list-panes always lists the panes of the currently active window when you try to make it list the panes of a window in another session. If the script above is executed in pane %1, everything works fine, but just since session $0 only has one window.

I would expect (in both cases):
$0 @0 %0
$1 @1 %1
$1 @2 %2
$1 @2 %3

Versions used:
tmux 2.0 (via Homebrew)
Mac OS X 10.9.5 (13F1077)

If a window title begins with a number and no window with that number exists, if we use prefix-number, we are taken to the window with that number in the title.

Example:

Say 3 windows exist:

0:win1
1:win2
2:7zero

Now, if I press prefix-7, I am taken to window 2 instead of getting the standard "Window not found" message.

I am unable to use the Home and End buttons when in copy mode.

Example
in tmux 1.9a
press Ctrl+b [
move the cursor up it is at the end of a line
press Home the cursor does not move
go to start of line
press End the cursor does not move

It often get stuck when editting something with vim ,what I can do is ctrl+b+& to close the window.Is this a bug???

Hello,

is it possible to disable the behavior which cause selecting a pane on opposite side of a tmux window if there is no more pane left in a direction select-pane command was originally triggered at?

if not, is there a way how to determine if any other panes exist in specific direction eg.: select-pane -L?

if a tmux window doesn't have any (v)splited window and a select-pane command is triggered, an error message is threw - this is expected behavior.

Thank you

It took me a while to figure out why my borders seemed totally messed up.

The marked pane's border colors are inversed.

The problem I have with this is that I think that the marked pane border-inverting should not trump the active pane border colors. IMHO, the active pane should be the pane with unbroken active-border-color on its border, and the inverting of the marked pane should not be allowed to encroach upon that.

Similarly, I think that maybe there should be an additional border style for the marked pane that we can specify colors for. using inverse for it seems limited and confusing as it was for me.

http://unix.stackexchange.com/questions/193943/passing-tmux-variable-into-shell-command-in-tmux-conf has a pretty decent discussion of the request. Allowing this would mean you could completely reimplement any format string via shell and would offer a lot more flexibility. Additionally, the behavior of shell commands format strings would be more like if-shell, which does interpolate format commands before running the shell.

tmux neither shows the possible completions (probably due to a single line available) nor does it cycle through possible completions.

IE: ":list-" doe nothing useful

learning curve would be reduces if a completion existed.

I want to be able to start the tmux server without forking the process, but I found no way on last tmux release.

I found this commit on cvs-archived repository:

ThomasAdam/tmux-cvs-archived@4ae5438

why it's not in the main tree?

This is originally reported at https://cygwin.com/ml/cygwin/2015-05/msg00314.html , how to reproduce. Build and compile the following Go program

package main

import (
"fmt"
"time"
)

func main() {
for i := 0; ; i++ {
fmt.Println(i)
time.Sleep(500*time.Millisecond)
}
}

Run it in one window and try to switch, it will eventually switch but will take a lot of time. And if you wait long enough it'll put title on the window. I have this semi-regularly happening with ssh running under a tmux window.

All Motion (CSI ? 1003 h) no longer has any effect. Cell Motion (CSI ? 1002 h) still works fine. This looks like a tmux issue to me. All Motion still works in XTerm(318) and urxvt v9.21 without tmux.

This issue cripples any terminal app that requires hover effects.

See: chjj/blessed#145

Hi there, I'm using powerline with tmux, I've already discussed with powerline owner about this issue at powerline/powerline#1410 but the problem seems with the length of the text being displayed in tmux.

If you look at powerline/powerline#1410 (comment) screenshots the issue seems to be the length of the status being set.
Also, tmux show-options -g seems to truncate its value, is that correct? Seems that after 165 bytes of content the tab disappear

I've tried to manually increase status-right-length but without any luck.

I have been using Ctrl + \ for a couple years now. Just in the past few days my prefix key stopped working and I get this error when opening Tmux.

/home/elijah/.tmux.conf:2: bad key: C-\\

How to reproduce:

• Debian GNU/Linux, KDE
• Maximize Konsole (sic!) terminal emulator
• Press "Enter" many times to bash (so, Konsole window should be filled with bash prompts)
• Type "tmux" to bash
• Restore the window to normal size
• Type "exit" to tmux

What I see:

• I get corrupted Konsole window. I see:

root@comp:#
[exited]p:#
root@comp:~# _

Tested with Debian Jessie, tmux 1.9, Konsole 2.14.2 (KDE 4). Also with current Debian Sid, tmux 2.0, Konsole 2.14.2 (KDE 4).

I think that this bug is unrelated with Konsole, KDE etc and should be reproducible with other emulators. Also, bug is not reproducible if I replace tmux (for example) with less

Hi,

Now that Github is the primary repo for tmux, my initial assumption was that pull requests would be the preferred way to submit patches. Since it is not, it would be nice to mention this in the readme.

Even though the Readme does explicitly say "Patches should be sent by email to
the mailing list at [email protected].", I can't be the only person that would assume PRs would also be welcome. If you don't want to receive them, a mention of this in the Readme would probably save you some time.

If I cd ~/myfolder and then open a new tmux pane split below the current one my directory goes back to my ~/ home folder. I would expect this to all be relative to my current path.

In tmux window with default settings, if I change directories, the window title will change.
However after I switch user, the title will never change.
This issue only appears in zsh in tmux. In bash in tmux, the window title is correct.

There is another similar issue for the status line.
If I set the status-left as
set -g status-left '#(echo $USER)@#H '
Then I see admin@dev
But whatever user I switch to, it always shows admin@dev.

Hey all, I've never had a noticeable issue with tmux before, but today I've had this happen twice. Not sure what's going on. The entire tmux process locks up, it pegs the CPU at 100% and won't respond to anything.

Here's a gist of the sample that I took while this was happening: https://gist.github.com/jfelchner/c81317e6fcebbbf85eae

Let me know if you need any more information.

Wenn starting tmux from an kmscon session tmux prints ^@u before the first bash-prompt and u directly after.

I am using kmscon 8-8.fc22 (Fedora)
and
tmux 1.9a-5.fc22 / tmux 2.1 (git: dcc2843)

How to reproduce:

• Start kmscon
  sudo kmscon --vt=/dev/tty3 --no-switchvt
• Switch to TTY3
• Start tmux
  $ tmux

Output:
^@u[myname@hostname] ~$ u

Hi guys
i update to tmux 2.0 and i have an issue with emacs/freebsd with the cursor
i load a tmux session without ~/.tmux.conf and the cursor in emacs it is back.

but my point is other :
i look for the /etc/tmux.conf and i can't find it in my system
why isn't a tmux.conf in the github ?

i have examples in /usr/share/tmux/
but isn't a real tmux.conf

tmux's man page says that :
FILES
~/.tmux.conf Default tmux configuration file.
/etc/tmux.conf System-wide configuration file.

it is any place for the file tmux.conf after install in the OS ??

thanks for your time

There was a very long thread about TrueColor support in Tmux that was on SorceForge. I'd be happy to convert it over, but it seems as though the link is no longer valid.

It was specifically issue number 140 which was the issue about truecolor support in Tmux.

Update: Here is all of the information I could find. Thanks to @ThomasAdam for the help.

The old URL was: http://sourceforge.net/p/tmux/tickets/140/
Archive Link: https://www.mail-archive.com/[email protected]/msg06296.html
Gist Link: https://gist.github.com/jfelchner/b0c44b1ac199df28fb84

Current TrueColor Terminal/Program Support Status: https://gist.github.com/XVilka/8346728

This crashes tmux. Also, if you have two panes open, this will cause the data in the pane running this to spill over into the other pane.

wget -O - http://distfiles.gentoo.org/releases/arm/autobuilds/20150607/stage3-armv7a_hardfp-20150607.tar.bz2

My cursor disappears when in a nested tmux session. It does work under a single session.

To reproduce:
$ tmux
$ unset TMUX
$ tmux
$ emacs
No cursor.

tmux 2.0
GNU Emacs 24.5.1
iTerm 2.1.1
Also tried it under Terminal.app (OSX 10.10.4 Public Beta)

I have built tmux from the 2.0 source tar. When I try to start tmux, it crashes with a return code of 1. I have posted the log generated from "tmux -vvvvv" are in gists.

Server log
Client log

On Linux vt's (TERM=screen) it is not possible to resize panes via C-Up, C-Down, C-Left, C-Right nor M-Up, M-Down, M-Left, M-Right.

Elimar

Steps to reproduce:

1. Set a large environment variable e.g.

export FOO=$(tr -d '\t\n ' < /usr/share/dict/words | dd bs=1k count=64)

2. Start tmux

tmux

If started with '-v' tmux writes 'fatal: server_client_msg_identify: bad MSG_IDENTIFY_ENVIRON string' to tmux-server-nnn.log.

Tested with tmux version 1.9 on Linux and 2.0 on OSX.

If you start selecting text with mouse from bottom of buffer, if the mouse goes off the terminal window, tmux stops updating mouse selection and highlights from starting point up to the half of the screen. If you start selection from top of terminal/buffer going down and mouse goes off terminal window, tmux highlights starting point and up to half of the screen. When mouse re-enters window, tmux doesn't continue updating the end of the selection point.

Expected behavior is that if selecting text with mouse, if mouse goes off terminal window selection end point will stop updating, but when mouse re-enters window, it picks back up and continues highlighting up to wherever mouse has moved to.

This was tested on OS X (iTerm) with tmux -HEAD from homebrew.

I would love to see support for libsixel in tmux. While I recognize that this is not something that tmux can do unless the underlying terminal supports it, at the moment, there does not seem to be a way to have sixel function at all within tmux.

Every now and then the command I've configured to run on C-j no longer works and a normal line feed (which is the code C-j produces) is triggered. When I look up the configured keys, everything is there except for C-j. It simply vanishes. This hasn't happened for any other key binding.

I'm really not sure how to reproduce this, but my gut feeling tells me that it happens when I'm using PostgreSQL's psql shell. Not sure whether it is technically possible that psql would mess with the keys. When I run the bind-key command as I have it in my .tmux.conf everything works again.

https://github.com/tmux/tmux/search?p=7&q=Sourceforge&type=Code&utf8=✓ Search for SourceForge still has some mentions in files. Most Notably the CHANGES file and copyright notices have peoples' names with @users.sourceforge emails.

Should this be cleaned up?

In https://gitlab.com/gnachman/iterm2/issues/3590 I reported a bug in iterm2 in which, under tmux, in some cases, multiline mouse-select of wrapped text includes newlines.
I've attached in that bug a reproducible test case. According to George Nachman (iterm2 dev), this is due to tmux not preserving the distinction between soft and hard newlines (see his answer here: https://gitlab.com/gnachman/iterm2/issues/3590#note_1368481)

Is that something that could be fixed?

It appears that copy-line (and copy-end-of-line) changed slightly in 2.0.

With mode-keys set to vi...
In 1.9a (and, i believe, in all previous versions since the functionality was added in 1.5) the trailing newline was not included; in 2.0 it is.
list-buffers shows the difference:

0: 19 bytes: "@raptor:~/tmux-2.0$"

buffer0000: 20 bytes: "@raptor:~/tmux-2.0$\012"

Was this an intended change? I didn't see any reference to it in the changelog.

For someone who used those features a lot, this is a big change.
Is it possible configure the old functionality?
Alternatively, if there was a way to bind a key to multiple commands in copy-mode I could compose the functionality myself, but I haven't been able to find a way to do that.

man clang

prints something...

tmux
man clang
No manual entry for clang

Hi,
this is a reply to the original issue 196 opened on sourceforge.
The problem was spotted on OSX where the default file descriptors limit is 256. When tmux used all the file descriptors, it would hang and the CPU would go to 100%.

Below is the copy/paste of the excerpts from the previous discussion.

I was able to reproduce the issue on Linux too. Here are steps to reproduce:

• test machine: Ubuntu 14.04 cloud VPS with 512Mb ram

• tmux -V is 2.0 (also tested on latest version from git, behaves the same)

• the default output of ulimit -n command is 1024. To "simulate" OS X default limit, this was reduced to 256 with the following command: echo 'ulimit -n 256' | sudo tee -a /etc/profile, and the machine was restarted

• tmux.conf:

  set -g prefix C-a
  set -g @success "yep"
  set -g status-right 'Script #(ping -c 1 www.google.com >/dev/null 2>&1 && printf "$(tmux show -gqv @success)")'
  

• start tmux

• the ping command in status-right works ok, displays "yep"

• use this command to create large number of windows for i in $(seq 1 150); do tmux new-window; done

• there's no output from ping command now. At this point tmux starts using 100% CPU sometimes. By doing the next step that happens consistently.

• In one of the panes run tmux show -g status-right. The command returns no output and at that moment tmux process CPU usage goes to 100% and never goes down. However, tmux stays responsive, windows can be changed and executing other commands works ok (which was not the case on OSX where things just freeze).

Even with the above steps, Nicholas wasn't able to reproduce the issue. The suggestion was to try the following:

Can you go to server_accept_callback in server.c and comment out this line inside the if (ENFILE EMFILE) bit:
/* Delete and don't try again for 1 second. */
server_add_accept(1);

So here's the update to this issue: unfortunately updating the above bit and recompiling didn't change anything. I can still get tmux to use 100% CPU consistently.

Idea for moving forward on this: what do you think about using the linux server where reproducing the issue is easy? Would that help?

I've created a linux server with everything set up (tmux installed, tmux.conf in place). Nicholas can ssh in with his keys and Thomas with his. IP is: 46.101.186.232. User is root. Tmux is cloned in /root/src/tmux. Feel free to do whatever you want on the server, I'll nuke it once we're done debugging.

Once again, steps to reproduce the issue consistently on the server:

• start tmux
• run for i in $(seq 1 150); do tmux new-window; done
• in one of the panes run tmux show -g status-right
• at this point htop should show tmux using 100% CPU

I hope that will help!

I am trying to switch from screen to tmux and discovered that I have a habit of doing this:-

1. Press C-a
2. Release the 'a' key
3. Press another key, according to whatever I need to do
4. Release the Ctrl key

In screen, this is tolerated. In tmux, however, a prefix of C-a does not function unless both keys are released prior to step 3.

I find this characteristic of screen comfortable and it's nigh on impossible for me to alter this habit. Is there any chance of introducing an option for tmux to allow for this sloppy use case?

I was surprised to find my email to tmux-users mailing list bounced. But GitHub is a great new home for tmux. Welcome to GitHub! (looks like mailing list is now on Google Groups)

I had a workflow that I quite liked which was that I would create grouped sessions and treat them in this way: each session "belongs" to a piece of physical hardware.

My laptop's session mac can stay on window 0, and my desktop's large portrait-oriented monitor can be used in session putty can stay on window 1. The beauty is that the list of windows are shared in the sessions and the dimensional constraints are lifted whenever the sessions focus on different windows.

I began to leverage more behavior based on sessions having their own environments. This is covered well in the manpage under ENVIRONMENT. What I took a liking to was that I could set $GIT_AUTHOR_NAME to a different value per session. This is really great because I can now train my shell to call tmux showenv and differentiate at the command level whether I executed the command from the tmux session corresponding to my laptop or the tmux session corresponding to my desktop. Indeed, setting the $GIT_AUTHOR_NAME accomplishes this very easily for Git.

OK. so this still works as well as it ever did -- that is to say, really well.

But in recent git builds, I have been noticing something sinister. Now, when I use choose-tree or switch-client to switch from session A to session B, session B's environment is completely overwritten by session A's session environment. This happens whether A and B are grouped or not.

Now this isn't a really unforgivable behavior, and it does certainly seem to fall outside of specified behavior, as far as the man page is concerned.

However, I do have to say that it is very useful to be able to temporarily switch to another session just to e.g. move it off to another window, in order to get screen space back, for instance. Now I do imagine that if I remain disciplined (maybe bind a key that does something tricksy to cause the other session to change its focused window, but without actually switching to it to blow away its environment) I can avoid the environment-nuking. But I think I have sufficiently described the use case at this point.

Thanks!

P.S. I have now also tested this without loading my (rather elaborate) tmux.conf, and also without running my (also elaborate) zsh shell with tmux by reverting my shell to bash. So, the behavior seems to be easily reproducible and this all but eliminates the possibility that other configuration is causing the behavior. Commit f7598b8, OS X 10.10.3.

Hi @ThomasAdam.

I build tmux HEAD.

Next, I tried printf "\x1b[48;2;71;85;91mCOLOR\x1b[0m\n", but result bg color is hex #4e4e4e.
In fact, 71;85;91 is hex #49555b

Why hex color is different?
Do you have any idea?

Environments

• OS X Yosemite and El Capitan
• iTerm2 and OS X Terminal
• xscope(Hex color check)

cmd-pipe-pane.c: In function 'cmd_pipe_pane_exec':
cmd-pipe-pane.c:130:43: error: dereferencing pointer to incomplete type
wp->pipe_off = EVBUFFER_LENGTH(wp->event->input);
^
make[3]: *** [cmd-pipe-pane.o] Error 1

Clean install of tmux 2.0 with no config causes strange output after running tmux send-keys -R

~ > ls
Applications   Documents      Library        Pictures
Desktop        Downloads      Movies         Public
Development    Dropbox        Music          VirtualBox VMs
~ > tmux send-keys -R
· > ┌⎽   # <--- this was ls
A⎻⎻┌☃c▒├☃⎺┼⎽   D⎺c┤└e┼├⎽      L☃b⎼▒⎼≤        P☃c├┤⎼e⎽
De⎽┐├⎺⎻        D⎺┬┼┌⎺▒d⎽      M⎺┴☃e⎽         P┤b┌☃c
De┴e┌⎺⎻└e┼├    D⎼⎺⎻b⎺│        M┤⎽☃c          V☃⎼├┤▒┌B⎺│ VM⎽

Just upgraded to tmux 2. I use this to open a new window, and prompt for a title:

bind-key -n "M-o" command-prompt -I "" "new-window -n '%%'"

tmux doesn't like having -I be empty, and gives me this error:

cmdq 0x7ff95aa25960: command-prompt -I  "new-window -n '%%'" (client 15)
fatal: xreallocarray: zero size

If I put a space for input, it works:
bind-key -n "M-o" command-prompt -I " " "new-window -n '%%'"

Not sure if there's a newer preferred way of opening a new window. My current fix works, and a real fix is definitely a low-priority for me, but wanted to document it as it could be causing issues for other people.

Would a PR changing the FAQ and README files to markdown be welcome?

Hello I'm openSUSE Maintainer for tmux

https://build.opensuse.org/package/show/utilities/tmuxHello I'm openSUSE Maintainer for tmux

https://build.opensuse.org/package/show/utilities/tmux

This patch i have found when have get Maintainer status

/usr/local/suse/utilities/tmux/ > cat tmux-socket-path.patch 
--- tmux-1.9a.orig/tmux.c
+++ tmux-1.9a/tmux.c
@@ -137,7 +137,7 @@ makesocketpath(const char *label)
        else if ((s = getenv("TMPDIR")) != NULL && *s != '\0')
                xsnprintf(base, sizeof base, "%s/tmux-%u", s, uid);
        else
-               xsnprintf(base, sizeof base, "%s/tmux-%u", _PATH_TMP, uid);
+               xsnprintf(base, sizeof base, "/run/tmux/%u", uid);

        if (mkdir(base, S_IRWXU) != 0 && errno != EEXIST)
                return (NULL);

and in old tmux.spec

/usr/local/suse/utilities/tmux/ >   cat tmux.spec
# PATCH-FIX-OPENSUSE tmux-socket-path.patch [email protected] -- Use /run/tmux instead of /tmp as the default socket path, this add some robustness against accidenta
l deletion via systemd-tmpfiles-clean, tmpwatch, or similar
Patch0:         tmux-socket-path.patch
...
%prep
%setup -q
%if %{with systemd}
%patch0 -p1
%endif

I have changed that use sed instead patch in tmux.spec

/usr/local/suse/home:nemysis:branches:utilities/tmux/ > cat tmux.spec
%if %{with systemd}
# SED-FIX-OPENSUSE [email protected] -- Use /run/tmux instead of /tmp as the default socket path, this add some robustness against accidental deletion via systemd-tm
pfiles-clean, tmpwatch, or similar
sed -i s'|"%s/tmux-%u", _PATH_TMP, uid)|"/run/tmux/%u", uid);|' tmux.c
%endif

Please add check for openSUSE in tmux.c and add this to Source.

Thanks,

This patch i have found when have get Maintainer status

/usr/local/suse/utilities/tmux/ > cat tmux-socket-path.patch 
--- tmux-1.9a.orig/tmux.c
+++ tmux-1.9a/tmux.c
@@ -137,7 +137,7 @@ makesocketpath(const char *label)
        else if ((s = getenv("TMPDIR")) != NULL && *s != '\0')
                xsnprintf(base, sizeof base, "%s/tmux-%u", s, uid);
        else
-               xsnprintf(base, sizeof base, "%s/tmux-%u", _PATH_TMP, uid);
+               xsnprintf(base, sizeof base, "/run/tmux/%u", uid);

        if (mkdir(base, S_IRWXU) != 0 && errno != EEXIST)
                return (NULL);

and in old tmux.spec

/usr/local/suse/utilities/tmux/ >   cat tmux.spec
# PATCH-FIX-OPENSUSE tmux-socket-path.patch [email protected] -- Use /run/tmux instead of /tmp as the default socket path, this add some robustness against accidenta
l deletion via systemd-tmpfiles-clean, tmpwatch, or similar
Patch0:         tmux-socket-path.patch
...
%prep
%setup -q
%if %{with systemd}
%patch0 -p1
%endif

I have changed that use sed instead patch in tmux.spec

/usr/local/suse/home:nemysis:branches:utilities/tmux/ > cat tmux.spec
%if %{with systemd}
# SED-FIX-OPENSUSE [email protected] -- Use /run/tmux instead of /tmp as the default socket path, this add some robustness against accidental deletion via systemd-tm
pfiles-clean, tmpwatch, or similar
sed -i s'|"%s/tmux-%u", _PATH_TMP, uid)|"/run/tmux/%u", uid);|' tmux.c
%endif

Please add check for openSUSE in tmux.c and add this to Source.

Thanks,

With the following settings, new panes appear to open in pwd -P instead of pwd. This is somewhat unintuitive (and annoying to hack around).

# Ubuntu 9.10

bind '"' split-window -v -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"

Current pane pwd: ~/dots
<split-window>
New Pane:/net/host/user/me/dots