Issue with using `-t` in pane commands in session files

[GBlackburnMicrosoft]

This issue is observed with both tmuxp 1.40.0 and 1.39.0, it was not present in 1.9.4.

Summary

When a pane command includes the string -t it will not enter that command into the pane and will instead print it to screen in the shell where you ran the tmuxp command.

Reproduction

Example configuration file:

session_name: "Some-Session"
windows:
  - window_name: "Some-Window"
    layout: tiled
    panes:
      - shell_command:
        - echo "t - This echo's correctly."
      - shell_command:
        - echo "-a - This also echo's correctly."
      - shell_command:
        - echo "-t - This is never sent to the pane and instead printed to the current shell."

Expected:
Load this template using tmuxp load and you'll get three panes, all three panes have echoed out the expected message.

Current outcome:
When loading this template only the first two panes will have echoed out the expected message and the final one with -t in it then it prints out to the current shell.

[tony]

Interested coincidence, as -t​ is reserved by tmux for targets under the hood. I will look closer this weekend.

…

________________________________ From: GBlackburnMicrosoft ***@***.***> Sent: Wednesday, March 6, 2024 8:43 AM To: tmux-python/tmuxp ***@***.***> Cc: Subscribed ***@***.***> Subject: [tmux-python/tmuxp] Issue with using `-t` in pane commands in session files (Issue #915) This issue is observed with both tmuxp 1.40.0 and 1.39.0. Summary When a pane command includes the string -t it will not enter that command into the pane and will instead print it to screen in the shell where you ran the tmuxp command. Reproduction Example configuration file: session_name: "Some-Session" windows: - window_name: "Some-Window" layout: tiled panes: - shell_command: - echo "t - This echo's correctly." - shell_command: - echo "-a - This also echo's correctly." - shell_command: - echo "-t - This is never sent to the pane and instead printed to the current shell." Outcome: Load this template using tmuxp load and you'll get three panes, all three panes have echoed out the expected message. Expected: When loading this template only the first two panes will have echoed out the expected message and the final one with -t in it then it prints out to the current shell. — Reply to this email directly, view it on GitHub<#915>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGNYE2FRA5QG2DWCWMA7TYW4TPLAVCNFSM6AAAAABEJGEYFGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE3TCNRXGM4TONY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tony]

@GBlackburnMicrosoft #916 has a recreation attempt using that tmux config almost exactly (across an array of tmux + python versions)

By deduction: This is potentially connected to your shell, shell configuration, or tmux configuration.

Can you provide these:

• A screenshot (to confirm what the final results looks like)
• tmuxp debug-info
  • tmux -V
  • tmuxp -V

On your side:

• can you try tmuxp load -L test -f /dev/null <path-to-config>? That will emulate a blank config, it's equivalent to tmux -L test (socket name of test to not interrupt existing tmux sessions.
• can you try experimenting with different shells / with and without shell configs? If you deduce what it was, it may be useful for others to know, and libtmux/tmuxp could use it to improve compatibility.

[GBlackburnMicrosoft]

Darn, I had hoped it wasn't a shell issue. Narrowing those down is painful. Here's the screenshot of after I've loaded my reproduction config above and appended it to the current session (note this is in my window after running tmux -Ltest new then using tmuxp load -L test -f /dev/null <path-to-config>:

Version details:

gblackburn:~/code/temp $ tmux -V
tmux 3.2a
gblackburn:~/code/temp $ tmuxp -V
tmuxp 1.40.0, libtmux 0.32.0

Debug info:
debug-info.log

I'll have a play around with my shell and see if removing something solves the issue. Thanks for taking a look and attempting to repro.

[GBlackburnMicrosoft]

I have just done another test with 1.9.4 and didn't see the issue. Sounds like there's some binary chopping I can do as well to narrow down when this was introduced.

[GBlackburnMicrosoft]

I've done the binary chopping and it all works as expected when:

gblackburn:~ $ tmuxp --version
tmuxp 1.36.0, libtmux 0.27.1

but I start seeing the issue when:

gblackburn:~ $ tmuxp --version
tmuxp 1.37.0, libtmux 0.28.1

From looking at the changelog the only change here is to take 0.28.0 of libtmux so potentially the issue is with them.

I'm going to do a little digging into my environment.

[GBlackburnMicrosoft]

I've done some more testing locally and I only see the issue when running the tmuxp command from within another tmux session and appending the template. If I run it from outside a tmux session then it works just fine.

I've managed to reproduce this in a UT (basically building on your one) in https://github.com/tmux-python/tmuxp/pull/917/files. Although I haven't had it run in Gitlab I could confirm locally that it reproduces the issue.

I'm unsure whether this is an issue with libtmux or how tmuxp is using it. I suspect that the relevant change in libtmux is:

@@ -113,7 +120,7 @@ class Pane(Obj):
         Specifying ``('-t', 'custom-target')`` or ``('-tcustom_target')`` in
         ``args`` will override using the object's ``pane_id`` as target.
         """
-        if not any(arg.startswith("-t") for arg in args):
+        if not any("-t" in str(x) for x in args):
             args = ("-t", self.pane_id, *args)
 
         return self.server.cmd(cmd, *args, **kwargs)

[tony]

I've done some more testing locally and I only see the issue when running the tmuxp command from within another tmux session and appending the template. If I run it from outside a tmux session then it works just fine.

Good obversation.

@GBlackburnMicrosoft Do you want credit for it for the fix on libtmux? If you want to make a PR against libtmux you can, so it shows up in git history. If not, I can make the change.

[tony]

If you want to make a PR against libtmux you can

@GBlackburnMicrosoft For this purpose, I will make the change. Based on finding tmux-python/libtmux#533 + CiscoDevNet/virlutils#148, this needs a different approach to ensure compatibility.

I think cmd needs:

• to have a target to passed as an optional keyword argument
• the if condition idiom needs to be removed entirely
• raise a warning if trying to pass a real target (any variation where [..., '-t', '{target value}'] or ['-t{target_value}'])