tmux-python / tmuxp

🖥️ Session manager for tmux, build on libtmux.
https://tmuxp.git-pull.com/
MIT License
4.05k stars 231 forks source link

Commands in shell_command do not run as expected #481

Open ksalman opened 5 years ago

ksalman commented 5 years ago

Step 1: Provide a summary of your problem

Step 2: Provide tmuxp details

[ksalman@dalaran:~] $ tmux list-panes 0: [105x26] [history 0/50000, 0 bytes] %1089 1: [105x26] [history 0/50000, 0 bytes] %1109 (active)

[ksalman@dalaran:~] $ tmux show-window-options -g aggressive-resize off allow-rename off alternate-screen on automatic-rename on automatic-rename-format "#{?pane_in_mode,[tmux],#{pane_current_command}}#{?pane_dead,[dead],}" clock-mode-colour blue clock-mode-style 24 force-height 0 force-width 0 main-pane-height 24 main-pane-width 80 mode-keys vi mode-style fg=black,bg=yellow monitor-activity off monitor-bell on monitor-silence 0 other-pane-height 0 other-pane-width 0 pane-active-border-style fg=green pane-base-index 0 pane-border-format "#{?pane_active,#[reverse],}#{pane_index}#[default] \"#{pane_title}\"" pane-border-status off pane-border-style default remain-on-exit off synchronize-panes off window-active-style default window-status-activity-style reverse window-status-bell-style reverse window-status-current-format "#I:#W#{?window_flags,#{window_flags}, }" window-status-current-style bg=blue window-status-format "#I:#W#{?window_flags,#{window_flags}, }" window-status-last-style default window-status-separator " " window-status-style default window-style default wrap-search on xterm-keys on

Step 3: Describe your environment

Step 4: Describe the problem:

Steps to reproduce:

Observed Results:

Expected Results:

Relevant Code:


session_name: test
windows:
  - window_name: test
    panes:
       - shell_command:
           - cd /var/log
           - echo foo
joseph-flinn commented 3 years ago

@ksalman I did not try replicating your environment, but from a quick test on my setup (Python 3.9, tmuxp 1.7.0, tmux 3.0a), I get the expected output from the example session yaml that you attached. Are you still having an issue with this? (I know it has been a while since you have opened this issue, but didn't want to close it without resolution).

markmuetz commented 2 years ago

I saw a similar issue as above, where I found that the shell_commands were not being executed (and it appeared as if a tab key was being inserted after the first command - a tab complete listing was coming up - perhaps related?). The behaviour is consistent across multiple machines running a variety of (old-ish, 2.1-2.9) versions of tmux. I had seen similar problems with my own bash script for launching tmux sessions, where I fixed it by adding in a sleep 10 call. I noticed that recent versions of tmuxp has a similar sleep_before option (undocumented?). For me this fixes my problem:

session_name: test
windows:
- window_name: test
  panes:
     - shell_command:
         - cd /var/log
         - echo foo
         sleep_before: 0.5

N.B. I think this is applied on a per-pane basis. It would be good if you could do this per-window (or even per-session), although I'm not sure if this is currently possible. Currently, this causes quite a lengthy wait for tmux to start up.

tony commented 2 years ago

N.B. I think this is applied on a per-pane basis. It would be good if you could do this per-window (or even per-session), although I'm not sure if this is currently possible.

I think it would be fine if you made an issue for this. It sounds like a good idea

piotr-dobrogost commented 2 years ago

Fixing bugs by inserting random sleep is definitely not a good idea…

tony commented 2 years ago

@piotr-dobrogost What do you propose?

piotr-dobrogost commented 2 years ago

I'm not familiar with the internals of the project and can only say what many others would say; we should investigate the problem and find the reason for this race. If the reason is that shell is not initialized as suggested earlier it seems the solution is to find a way to wait for shell's initialization to be completed before running commands.

markmuetz commented 2 years ago

@piotr-dobrogost I agree in principle. Adding a sleep is definitely a workaround. It does work though. I am happy to investigate further or provide info on my tmux setup, but this does affect me on multiple computers. For me, and for the time being, adding in a short sleep is acceptable.

It seems like what is needed is either polling the shell to see if it accepting commands, or a callback that is triggered after the shell has been initialized. However, I don't know about the internals well enough (or the intersection between tmux/bash/tmuxp/libtmux) to know if either of these is possible.

piotr-dobrogost commented 2 years ago

Googling for tmux wait for shell brings this Tmux in bash script executing too fast. The title is probably not quite right, the answer (needlessly?) uses sleep but what is interesting is that they use tmux wait-for which maybe could be a better workaround than plain sleep.

tony commented 2 years ago

@piotr-dobrogost @markmeutz

tmuxp isn't in control of shell commands themselves finishing. that is why sleep exists.

there may be ways to do such a thing but having it done in a portable + simple fashion is another question.

tony commented 2 years ago

It seems like what is needed is either polling the shell to see if it accepting commands, or a callback that is triggered after the shell has been initialized. However, I don't know about the internals well enough (or the intersection between tmux/bash/tmuxp/libtmux) to know if either of these is possible.

These may be possible in the future but would need to be organized into their own issues