Note: These debug additions need to be temporary since they will cause problems if you ever use a program that makes automated logins (e.g. The errors may not actually be in your startup file itself, but in a script that it runs.Once you know which file is being processed when the errors occur, add more debug outputs around each “major block” or line to narrow down the responsible section/line.If the errors happen before that file, then the problem may be in /etc/profile. If not, instrument your other startup files. bashrc to see if the error occurs during your. If you find the -vx output too verbose, you could try “printf debugging” (manually adding debug statements to your startup files until you can narrow down exactly which lines are causing the errors): The shell errors are probably due to some problem in your startup files (or something they run).Īs shellter commented, temporarily including the command set -vx early in your startup sequence is a good way to find out where the errors are occurring. Is there a better way to set up a tmux session over several directories? I have no idea why this happens, but I still think that I’m not doing this right.
#Tmux new window windows
But if I start more than about 4 windows, I frequently see the following bash errors in one of the windows after startup: bash: [: =: unary operator expected Tmux new-window -t xyz:6 -n var6 'cd /var/log bash -i' Tmux new-window -t xyz:5 -n var5 'cd /var/log bash -i' Tmux new-window -t xyz:4 -n var4 'cd /var/log bash -i' Tmux new-window -t xyz:3 -n var3 'cd /var/log bash -i' Tmux new-window -t xyz:2 -n var2 'cd /var/log bash -i' Tmux new-window -t xyz:1 -n var 'cd /var/log bash -i' So my next idea was to start a new shell like this: tmux new-session -s xyz -n etc -d 'cd /etc bash -i' Tmux new-window -t xyz:1 -n var 'cd /var/log'īut I soon found out that this will not work as I expected - the window will be closed after the shell command completes. I started with a script I found and tried this first: tmux new-session -s xyz -n etc -d 'cd /etc' There is tmux wait-for to handle such situations (but using it right can be tricky see "Dealing with race conditions" in this another answer of mine).I want to use a script to open a tmux session with 6 windows, each in a different directory. Even with sleep 2 (or even with sleep 2000) there is no guarantee new-session runs first, only high probability. In the above example sleep 2 delays attach-session so it hopefully runs after new-session. By changing the current pane (or window etc.) or destroying some pane (or window etc.) you can cause the "maintenance" commands to target the wrong pane (or window etc.) or to fail unless they are carefully crafted to handle such situation.
This method has serious disadvantages though: This way you can actually see a new window popping out in tmux. Here you don't have to wait that long, you attach before tmux new-window runs. With the previous solution you would have to wait until all of them finish. Sleep 5 simulates commands that take time. Example (run it outside of tmux): (tmux new-session -d sleep 5 tmux new-window) & sleep 2 tmux attach-session And you want some logic to handle a situation when the named session exists etc.Īn alternative approach is to invoke some "maintenance" commands from a subshell running asynchronously and attach early from the main shell, with the "maintenance" part still running in parallel. In general you want to name and target the exact session, window etc. This example (run it outside of tmux) will attach to a session where an additional window already exists: tmux new-session -d If you eventually want to attach then tmux attach-session should be the last command in the script (unless you deliberately want to do something extra after you detach). Set everything up using commands that don't attach to the session (e.g. Do it without destroying the session, attach again and you will see the new window. If you detach then you will allow the script to continue. You cannot see the effect of tmux new-window before you detach because this command has not been executed yet. The script waits for this tmux to exit before executing the next command. One or the other tmux command becomes a tmux client and it runs until you detach. In your script tmux attach-session or tmux new-session attaches to a session. Tmux new-session tmux new-window is no different. You will see done only after you exit from less (with Q). Are you surprised echo works only after sleep exits? The shell runs the two commands in sequence, not in parallel.
0 kommentar(er)
