If I do the "history" command in tmux, I get a really weird result. Anyone got a hint on what to do to get normal output?
The output looks like this:
477 ◆┬▒⎺▒└☃◆ 478 c▒├ ◆┬▒⎺▒└☃◆ 479 ec▒⎺ ◆┬▒⎺▒└☃◆ 48▮ ┴☃└ ·/↓├└┤│↓c⎺┼° 481 ├└┤│ 482 ┌⎽ 483 cd ┐⎺▒┼⎽/ 484 ┌e☃┼ ┐⎺▒┼⎽ ⎼┤┼ 485 ┌⎽ 486 ┌e☃┼ ▮1_e─┤▒┌☃├☃e⎽↓c┌┘ ⎼┤┼ 487 cd ↓↓ 488 ┌e☃┼ ┐⎺▒┼⎽ ⎼┤┼ 489 cd ┐⎺▒┼⎽/ 49▮ ┌e☃┼ ┐⎺▒┼ ⎼┤┼ 491 ┴☃└ ▮1_e─┤▒┌☃├☃e⎽↓c┌┘ 492 ▒☃⎽├⎺⎼≤ 493 ┌e☃┼ ┐⎺▒┼ ⎼┤┼ 494 ├└┤│ ┌⎽ 495 ├⎺⎻ 496 ▒☃⎽├⎺⎼≤ 497 e│☃├ 498 e│☃├ 499 ▒☃⎽├⎺⎼≤ S⎼e┼⎽↑M▒cB⎺⎺┐↑P⎼⎺↑2:· S⎺e⎼e┼$
I'm guessing it has to do with encoding.
I'm on a MacBook Pro in OSX Lion 10.7.5.
I'm using the Terminal app which has (among others) UTF-8 encoding enabled and UFT-8 under "International - Character Encoding:".
My shell is bash.
My tmux as per
tmux -V is tmux 1.9a.
~/.tmux.conf/, I have
set-option -g prefix ^Space bind-key ^Space send-prefix unbind C-b set-option -g status-fg white set-option -g default-command "reattach-to-user-namespace -l bash" set -sg escape-time 1 set -g base-index 1 setw -g pane-base-index 1 bind r source-file ~/.tmux.conf set-window-option -g utf8 on set -g utf8 set -g status-utf8 on
languagesetup is English, though I'm Danish and so is my keyboard layout :) This has only been a problem for me when
languagesetup was not English - specifically, piping with my Danish pipe character
| meant that bash would not recognise the command after the pipe if I wrote a space between it and the pipe, so I had to do e.g.
echo $PATH |less
echo $PATH | less
But as I said, I fixed this with
I'm really eager to get going with tmux, so I hope somebody knows how to fix it! :)
The weird output was because I had ^N (the output from the key combination of Ctrl + n) in my history. The weird output can be intentionally forced if I press Ctrl + n followed by enter in tmux. I filed a ticket at tmux's SourceForge page in case it was a bug: https://sourceforge.net/p/tmux/tickets/137/ So, no ^N, no weird output!
For more interesting details, just look in the comments :)
After filing a bug report for the tmux developers at https://sourceforge.net/p/tmux/tickets/137/ , I have been told that the effect of ^N is not a bug. It is a feature from the olden pre-utf-8 days of hardware terminals, where developers used control characters to switch character sets in order to have access to a wider range of characters. ^N would "shift out", ^O would "shift in", that is, back to the original character set. Pressing ^O does not do anything for me in Terminal nor iTerm, and this is because ^O is remapped to "discard" - this can be seen by running
stty -a. However, after having done ^N, you can run a shell script
printf '\x0F', which inputs the control character that ^O is supposed to produce, and the output will return to normal, as you "shift in".