tmux-MacOSX-pasteboard
tmux-MacOSX-pasteboard copied to clipboard
shell not starting randomly
Hi, When adding reattach-to-user-namespace i do get the following behavior under 10.7: shell does not always start : http://cl.ly/211P0M3n2u0x2A1c0d2y
I started tmux in verbose mode (tmux -v) :
https://gist.github.com/1370201
thanks for helping
The screen shot shows that the window name is zsh
. By default, tmux will (try to) automatically rename the window based on the active process of the window’s active pane (i.e. unless you have turned off the automatic-rename
window option). So, unless you explicitly gave the window the name zsh
1, then an instance of zsh was probably started, it apparently just did not “finish” (i.e. print its prompt and start accepting commands).
Since the shell looks like it has at least started, I would start investigating by tracing its startup sequence. For zsh the earliest user-writable startup file is .zshenv
. If you (temporarily!2) put set -x
at the top of your .zshenv
, then you should see trace lines printed for each command the shell executes during its initialization. The last command printed before it “hangs” is the next place to investigate.
One possibility is that it may not be hanging at all, but you may (for some reason) have an empty prompt (i.e. a buggy startup sequence that sometimes unsets/empties PROMPT/PS1); the shell may actually be waiting for input. You might just try typing a command (e.g. echo hello
) at the blank screen to see if it the shell reads and executes it; if it does, then you should examine your startup files to find out why the prompt is sometime being blanked out.
Note: If you are using tmux’s default-command
to run your shell “through” reattach-to-user-namespace
, you will not see the wrapper program in the trace output because it has already finished its work by the time the shell starts.
1 Windows can be given an initial name via new-session -n winname
or new-window -n winname
. They can be manually renamed with rename-window
. All of these methods turn off the automatic-rename
option of the relavant window.
2 Setting the trace option in a startup file needs to be temporary because (besides producing an annoying amount of output with each instance of zsh) it can break some programs that do not expect to see such output (i.e. programs that use zsh-based scripts and programs (rsync, git, etc.) that make automated remote logins).
This issue looks like it can be closed.