Respawning panes and remain-on-exit

[z]

Using YAML, is there a way to respawn a pane and run the commands for that pane again?

I've tried:

session_name: respawnable
windows:
- window_name: watchers
  options:
    remain-on-exit: on
  layout: tiled
  panes:
    - shell_command:
        - ls
    - shell_command:
        - ls

I was expecting when I sent: respawn-pane -k for "ls" to reload. This is not the case.

Thanks.

[tony]

What version of tmux and tmuxp is this? What shell (bash, zsh, tcsh, etc.)?

I am not familiar with pane respawning. I am interested in your use case however, since it'd help me get familiarized so I can be of more help.

Can you get into more specifics on why you're using respawn-pane/trying to rerun commands again via yaml?

[z]

Often I use tmux to wrap multiple running components of a project, sometimes I will need to restart ones of those components.

For example, if I'm using a web server with a filewatcher and something breaks the watcher; I want to adjust the code that killed the watcher and restart just that pane within my tmux session.

Here is a test case to demonstrate this behavior:

Setup

start.sh

#!/bin/bash
tmux new-session -d -s "respawn-example"
tmux set -g remain-on-exit on
tmux selectp -t 0                      
tmux split-window -v './test-script.sh'
tmux -2 attach-session -d 

start.yaml

session_name: respawnable
windows:                 
- window_name: watchers  
  options:               
    remain-on-exit: on   
  layout: tiled          
  panes:                 
    -                    
    - ./test-script.sh   

test-script.sh

#!/bin/bash
ls
date
echo "finished loading"

.tmux.conf (add hotkey to reload pane)

bind-key R respawn-pane -k \; display 'Respawned Pane!'

Run

chmod +x start.sh
chmod +x test-script.sh

Expected behavior (bash):

./start.sh

Unexpected behavior (yaml):

tmuxp load start.yaml

Test

Use the respawn hotkey on the pane that contains the ./test-script.sh command.

Result

Expected:

The script (test-script.sh) reloads (you can see the date change).

Preview of a pane that's died without closing:

Unexpected (using tmuxp yaml):

The script (test-script.sh) runs once; I cannot tmux respawn-pane -k either with my hotkey or typing it into the console.

The output is:

 ./test-script.sh
z@zap:~/dev/tmuxp-play %  ./test-script.sh          
activate  start.sh  test-script.sh  test.yaml  venv
Mon May 16 20:23:30 EDT 2016
finished loading
z@zap:~/dev/tmuxp-play % 

I could repeat the command by pressing 'up' to activate the history, but I would like to know if there is a way to respawn-pane the tmux way and re-execute the command it spawned with.

If I type "exit" in the pane, I will see "Pane is dead," however "respawn pane" gives me only an empty terminal.

Software Details

I'm using:

tmux 1.8-5
tmuxp 0.10.0
zsh 5.0.2-3ubuntu6

Please let me know if you'd like any more information. Thanks.

[tony]

Is tmuxp preventing this? I'm trying to determine if this is a general tmux question, a bug or a question of how to approach this problem with tmuxp.

I haven't used the respawn behavior before.

For example, if I'm using a web server with a filewatcher and something breaks the watcher; I want to adjust the code that killed the watcher and restart just that pane within my tmux session.

What file watcher are you using? I haven't add this exact itch to scratch, but for similar things, I'll wrap it in entr(1) (if watching files) or a supervisor process (if uptime was critical). It it was a supervisor process, I'd tail -F the logs in a pane.

[kmactavish]

I think that this stackexchage post covers what is known on this topic.

[z]

@tony my apologies, I missed your previous message notification.

To clarify, this is a tmux behavior that I would like to be able to set in a tmuxp YAML definition.

I would like to be able to set a session, window or pane to "remain-on-exit".

In my test case above, I was intending to show the result of a pane remaining open with an exited script. The pane could be dead for any number of reasons, but the part I'm interested in, is the ability to "respawn-pane", e.g. re-run the command it launched with.

Below are excerpts from the man page that describe the behaviors. The link above, from @kmactavish, may offer further clarity.

respawn-pane [-k] [-t target-pane] [shell-command]
              (alias: respawnp)
        Reactivate a pane in which the command has exited (see the remain-on-exit window option).  If shell-command is not given, the com‐
        mand used when the pane was created is executed.  The pane must be already inactive, unless -k is given, in which case any existing
        command is killed.

set-remain-on-exit [on | off]
                     Set the remain-on-exit window option for any windows first created in this session.  When this option is true, windows in
                     which the running program has exited do not close, instead remaining open but inactivate.  Use the respawn-window command
                     to reactivate such a window, or the kill-window command to destroy it.

remain-on-exit [on | off]
                     A window with this flag set is not destroyed when the program running in it exits.  The window may be reactivated with the
                     respawn-window command.

Hope this helps, thanks.

[z]

I have updated my test case with more information.

[tony]

@z The thing is I just don't use this part of tmux.

I just used the yaml file from your original post #139 (comment)

tmuxp is setting remain-on-exit to on.

❯ tmux show-window-options
automatic-rename off
remain-on-exit on

Are you correctly seeing the window option when you load a tmuxp config?

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.

This bot is used to handle issues where the issue hasn't been discussed or
has gone out of date. If an issue isn't resolved and handled in a certain
period of time, it may be closed. If you would like your issue re-opened,
please create a fresh issue with the latest, up to date information and
mention this issue in it.

[jerri]

It seems this bug was never fixed. Is there any chance for a second look into this? Or is there a workaround by now?

[jerri]

Just to add some information to this topic. The problem stems from tmuxp starting a shell in windows by default and then sending any further applications to be started via send-keys. This way, when you use the respawn-pane functionality, only the shell gets restarted.
What you usually do is start an application in a window by adding the command to the window-creation call. In this case when the application stops and you respawn the pane, the application gets restarted again.
tmuxp uses Window.split_window from the libtmux-library. There the command to start in the new pane is awkwardly named shell instead of command. Therefore a possible workaround for starting commands compatible to the respawn-functionality would be to allow to define a shell per window. This wouldn't help when you need several panes on one window, then you would have to be able to specify an actual command to be executed in a pane.
Not sure how complex it is to extend the configuration of tmuxp. I also don't have too much time to implement something like this right now in tmuxp.

[tony]

@jerri I removed the stale from this and add Pinned so stale bot doesn't close this again

We are open to PRs in a case like this (including a testcase)

[jerri]

I guess the easist approach to this would be to add a parameter "shell" to the panes level. This way you could do a lot of cool stuff. E.g. you could for just one pane set python as the shell and then all the stuff added via shell-commands is going to be added to that environment. I checked out the code, but haven't find my way around it yet. But I think I would like to try to add this to the system.

[jerri]

I created a first implementation here https://github.com/jerri/tmuxp/tree/issue-139 . A demo file would look like this:

session_name: just-a-test
windows:
  - window_name: test window
    window_shell: /usr/bin/python2
    layout: even-horizontal
    suppress_history: false
    options:
      remain-on-exit: true
    panes:
      - shell: /usr/local/bin/python3
        shell_command:
          - print("Hello World")
      - shell: /bin/bash
        shell_command:
          - echo "Hello World, too"
      - shell_command:
          - print("Hello World 2")

I also fixed a bug with this code, I believe, because right now window_shell would only affect the first pane. Further panes created after the first pane would still use the default shell.

Next I would like to create a test for this addition. But I am not quite sure I fully understand, how the test system works and how you are testing against real tmux. Maybe someone can help me here. On top, unfortunately, the tests don't seem to run through on my mac. The tests in test_workspacebuilder.py seem to hang at some point. Right now I can't really see where.

On top, is this change actually relevant for the project? I found, that I can workaround my current problems using window_shell, but if you really would like to use remain-on-exit also for several panes, than the change I propose would be required.

[tony]

@jerri I reopened this issue (sorry it was closed)

On top, is this change actually relevant for the project? I found, that I can workaround my current problems using window_shell, but if you really would like to use remain-on-exit also for several panes, than the change I propose would be required.

I'm not quite sure - but it's good we're having the conversation. Can you make a pull request of this branch as well?

Can you explain the use case for remain-on-exit? Personally, I've never used it. That's my biggest difficulty at the moment.

Next I would like to create a test for this addition. But I am not quite sure I fully understand, how the test system works and how you are testing against real tmux.

Hm.

This is a good time for me to improve our developer documentation. How familiar are you with python? pip? poetry? py.test?

How far along does this get you? https://tmuxp.git-pull.com/developing.html

1. Install poetry
2. tmuxp load path/to/your/tmuxp_checkout/.tmuxp.yaml

That should automatically have you an environment with tests that automatically re-run when files are edited.

[jerri]

Thanks for the info. I will check it out this evening.

Regarding the use case for remain-on-exit. I use tmuxp to start a standard session with relevant tools I use. E.g. my mail client (neomutt) or an irc client (irssi). I want this tools to be always at the same place. So, when I have to restart them, I just quite them, as usual. The pane doesn't vanish and I can just respawn-pane to get the application back running. Helpful also when I change e.g. configuration for those tools and just want them to restart again.

So, right now as a workaround I just use window_shell, as I don't use split windows right now. But I can image using split windows and than I would need this pane shell configuration to make this possible.

Apart from that I like the idea of having the capabilities to specify the shell per pane (like in the example provided above).

[tony]

Regarding the use case for remain-on-exit. I use tmuxp to start a standard session with relevant tools I use. E.g. my mail client (neomutt) or an irc client (irssi). I want this tools to be always at the same place. So, when I have to restart them, I just quite them, as usual. The pane doesn't vanish and I can just respawn-pane to get the application back running. Helpful also when I change e.g. configuration for those tools and just want them to restart again.

I wish I had a recording of what that workflow would look like. I'm slowly getting more familiar with this issue and how workspace_bulider could be getting in the way.

The reason why is I have the habit of thinking of restoring tmux in terms of a whole session, tmuxp/tmuxinator/teamocil is about restoring the whole session - it just does it for the whole session rather than a pane.

In regards to your branch, please do PR it, let's see how our test suite handles it.

[jerri]

Sorry for delay. Didn't have a lot of time lately.

I will clean up my branch and will do a PR. I will see if I can make a screencast to showcase how I am usually working. Might help to make it more easily understandable. I will also try to add a meaningful example to the examples documentation.