While writing code inside a tmux session, I inadvertently pressed a sequence of keys that has made my status bar disappear.
I haven't touched my tmux config file, and I verified the status bar is visible in new tmux sessions. Disconnecting and reconnecting to this session didn't help.
Read through the man page and searched through Google, no luck so far.
Running the following commands from inside the session didn't help:
^B :set-option -g status-bg default
^B :set-option -g status on
I have many windows open and would prefer not to have to destroy this session. Any help would be appreciated.
From the tmux command line, issue:
:set status on
to turn the status bar on. You can simplify this by adding a line to your .tmux.conf:
# toggle statusbar
bind-key b set-option status
and then reload your config.
Not quite a solution, but a possible workaround.
I'll assume your old session is number 0; adjust the argument to -t as necessary.
tmux new-session -t 0
This creates a new session which has all the same windows as session 0. If you create a new window in one session, it appears in the other as well. If you delete a window from one, it is removed from the other. More importantly, the new session should have a status bar. Then, you can try removing the old status-free session:
tmux kill-session -t 0
This should not affect the windows in session 0, since they are all part of your new session as well.
Related
This has been puzzling me for a while. I use tmux on a remote server via ssh. Tmux makes sure I don't have to worry about accidentally losing connection to the server. However, I found out every time I lost the connection, my terminal keeps reporting mouse interactions.
Losing connection to remote tmux session, will firstly give me this message client_loop: send disconnect: Broken pipe. After this, all mouse interaction within this
shell session will show following gibberish. It requires me to open another shell session to get rid of this behavior. This happens both to my macOS Terminal and another terminal emulator I'm using, kitty. Therefore I believe this is due to some bad configuration in my shell or tmux.
0;58;42M0;58;42m65;50;44M66;50;44M65;50;44M65;50;44M65;50;44M66;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M64;50;44M64;50;44M64;50;44M64;50;44M64;50;44M66;50;44M64;50;44M64;50;44M64;50;44M64;50;44M65;51;50M65;51;50M65;51;50M65;51;50M67;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M0;1;44M32;2;44M32;3;44M32;4;44M32;5;44M32;6;44M32;7;44M32;8;44M32;9;44M32;10;44M32;11;44M0;11;44m0;20;48M0;20;48m0;20;47M0;20;47m0;53;50M0;53;50m0;63;47M0;63;47m
My tmux version is 1.8. And the tmux.conf file has the following mouse related lines
# Use mouse
setw -g mode-mouse on
set -g mouse-select-window on
set -g mouse-select-pane on
set -g mouse-resize-pane on
set -g mouse-utf on
I'm wondering if anyone knows how to resolve this.
Many thanks in advance!
I'm using zsh and byobu (using the tmux backend).
In my .zshrc file I put the following:
if which byobu >/dev/null 2>&1; then
# if not inside a byobu session, and if no session is started,
# start a new session
test -z "$TMUX" && (byobu attach || byobu new-session)
fi
If I close the terminal emulator I'm using, then open another one, I re-attach to the byobu session I was using and all is fine. However, when I just start my computer, or if I exited byobu (for example by pressing Ctrl-D on the last open window), opening a new terminal results in this:
[exited]
~$
It seems to be because byobu attach actually returns something, so byobu new-session is never run, but I don't understand why byobu attach finds something if I quit byobu (in this case, $TMUX is empty).
How can I make sure that a new session of byobu is launched if there is no instance already running?
Thanks!
I was wondering if it is possible to completely reset tmux (the UI mainly) ?
I have tried deleting my ~/.tmux.conf and reinstalling tmux it but I always ended up with the same status bar I had defined.
Had forgotten to kill the existing sessions:
tmux kill-server
was the solution (credits to: #Kent)
I help maintain a large number of Unix-like servers, and so keep a script called tmux-rebuild that I use to rebuild all the tmux sessions and windows with SSH links to each server.
I have tmux configured to show the window's name in red with an exclamation mark in its status bar when a terminal bell character is printed in that window. This is very handy for programs like irssi alerting me to when I have messages in another window.
I also have my $PS1 set up on every server to print a terminal bell at the end of every prompt. This is useful because if I run a long job in one window and switch to another, I can immediately see when it's finished because when my prompt is written to the screen after the job is done, tmux makes the window name come up in red with an exclamation mark. This is great for my workflow.
However it causes a slight problem with the rebuild script mentioned above, because when I start up tmux after running it, every window in every session is flagged in red, due to the first prompt being printed to the screen. This makes the feature useless until I visit every window, and there are something like 40-50 of them.
Is there something I can add to my script that will clear all alerts from sessions and windows after they are created? I don't mind using a kludge if necessary.
From the tmux man page, specifically the last sentence here:
kill-session [-aC] [-t target-session]
Destroy the given session, closing any windows linked to it
and no other sessions, and detaching all clients attached
to it. If -a is given, all sessions but the specified one is
killed. The -C flag clears alerts (bell, activity, or
silence) in all windows linked to the session.
So, simply:
tmux kill-session -C
Figured out an acceptable workaround; I redefined the next/previous bindings to allow repeats:
# Allow repeats for next/prev window
bind-key -r n next-window
bind-key -r p previous-window
This allows me to quickly sweep up the alerts for all windows in a session by pressing my prefix key and tapping "n" until they're all clear, and I'm back in my original window.
With tmux 1.6 (and later), list-windows can generate customizable output, so it is fairly simple to read the output lines and make a loop that runs select-window for each window.
Add list-session (to loop over all sessions, optionally), and display-message (to parse session specifiers, and to record the current/“last” windows so they can be properly restored), and you might end up with something like this:
#!/bin/sh
# usage: tmux-select-each [session [...]]
#
# Select every window in specified session(s). If no sessions are
# specified, process all windows in all sessions.
#
# This can be handy for clearing the activity flags of windows in
# freshly spawned sessions.
if test $# -gt 0; then
for session; do
tmux display-message -p -t "$session:" '#S'
done
else
tmux list-sessions -F '#{session_name}'
fi |
while read -r session; do
active_window=$(tmux display-message -p -t "$session:" '#S:#I')
last_window=$(tmux display-message -p -t "$session:"\! '#S:#I' 2>/dev/null)
tmux list-windows -t "$session" -F '#{session_name}:#{window_index}' |
while read -r window; do
if test "$window" = "$active_window" ||
test "$window" = "$last_window"; then
continue
fi
tmux select-window -t "$window"
done
if [ -n "$last_window" ]; then
tmux select-window -t "$last_window"
fi
tmux select-window -t "$active_window"
done
We have an attended-upgrade script which launches apt-get update && apt-get upgrade simultaneously on all our administered systems. Ideally, we'd want to launch them all inside a screen session. When I do it like this:
File: upgrade.sh
for host in $ALLHOSTS
do
some_commands_which_take_considerable_time
screen -X screen sh -c "ssh $host \"apt-get update && apt-get upgrade\""
done
$ screen ./upgrade.sh
, it works, but as there are new windows arriving on the session, they are automatically being switched to. Instead, I'd rather have a version where the active window is fixed unless contained process quits or I switch manually using ^A n.
Bonus points if there is a possibility to preserve windows with exited processes, but keeping them separate from windows with active processes.
You can do this with tmux. For example:
# Start a session named "apt-get" and leave it running in the background.
tmux session-new -d -s apt-get
# Preserve windows with inactive processes.
tmux set-option -t apt-get set-remain-on-exit on
# Start a new window without switching to it. You can also do this from
# within a running tmux session, not just outside of it.
tmux new-window -d -t apt-get -n upgrade-$host \
"ssh $host 'apt-get update && apt-get upgrade'"
Note that you can have multiple windows with the same name, or modify the argument to the -n flag for unique names. The tmux application doesn't care.
As an example, you could name each window "upgrade," but that would make it difficult to identify your SSH sessions at a glance. Instead, this example appends the value of the host variable (populated by your for-loop) to each window name. This makes it easier to navigate, or to programmatically close windows you are no longer interested in. This is especially valuable when you have a lot of unclosed windows displaying terminated processes.
Overall, the syntax is a little cleaner and more intuitive than GNU screen's for this sort of task, but your mileage may vary.
W/r/t preserving windows after a subprocess exits, one possibility is to invoke the zombie command in your screen config file(s), which requires that you specify two keyboard characters that kill or resurrect the window, respectively. E.g.:
zombie KR
Then, K would kill a window whose subprocess has terminated, while R would attempt to relaunch the subprocess in the same window. Note that, in a zombie window, those keys are captured at the top level (i.e., do not precede them with your normal screen control character prefix sequence).
In order to prevent automatic switching to a newly created window, try altering your invocation of screen to something like the following:
screen -X eval 'screen sh -c "ssh $host \"apt-get update && apt-get upgrade\""' 'other'
Thanks to CodeGnome, I'll probably go with tmux as I believe there is no way to do it with screen (that's unfortunate, really!).
To give a better sketch of how it can be used:
#!/bin/sh
tmux new-session -d -s active
tmux new-session -d -s inactive
tmux set-option -t active set-remain-on-exit on
for host in $ALLHOSTS
do
tmux new-window -d -t active: -n upgrade-$host "
./do_upgrade_stuff.sh $host
tmux move-window -s active:upgrade-$host -t inactive:
"
done