evnp
commented
4 months ago Hi @dajabe, sorry about the long delay in response here, you caught me at an overwhelmed moment.
Your use-cases make sense – it's very constructive criticism that use-cases of tmex that involve running it within other tmux workflows are not very well fleshed out. One of the goals of the project is simplicity, but as long as we can expose new functions one-by-one under flags and keep default behavior easy to understand, I'd be happy for the tool have these new capabilities. Very open to PR(s) if that's something you have time/interest in putting together.
I'll clarify quickly what these three flags do (you may already know these details from looking at code):
-s / --shellless – Makes tmex pass command text to tmux directly instead of using send-keys to a shell in a tmux pane. This is a lighter-weight way of running commands without shells, but panes die and are non-interactive after commands exit.
-d / --detached – Simply makes tmex add the -d flag when executing the constructed tmux command, so the session is started in the background. This generally seems useful when running many tmex commands in a loop to spawn a bunch of sessions.
-r / --reattach – This doesn't have any effect if a session matching the provided session name doesn't yet exist, it executes a tmux command constructed from tmex args same as if -r wasn't passed. If a matching tmux session does exist, it ignores all other args and instead executes tmux attach-session -t <session-name>. This is sort of a special case for -p where this second case isn't reflected in the output, because of the "environment-state-dependent" nature of this command. The logic for this can be found here.
Your suggestion of a flag to replace new-session with new-window seems very straightforward to me and worth doing. Open to any design that you may have in mind – what comes to mind as clear to me is a --command="new-window" / -c new-window param that would be used to specify an alternate "command" in parlance of the Tmux man page.
Running with the -r flag results in the the operation trying to launch another tmux session within another session which is not ideal. The other option would be to check for the $TMUX env var and adjust the command automatically. Then a flag to force a specific behaviour if you don't it to run a new session regardless.
Tmex already attempts to do something like what you describe – splitting the pane further instead of trying to execute nested tmux commands if $TMUX_PANE env var is set. The logic for that is here. I'm curious if this behavior isn't working in your use-case, or if you're looking for something different?
Anyway, I'd welcome any changes in the form of PRs if you have the bandwidth. If you'd prefer I think I can put some time into a --command param in the very near future. Let's discuss potential design and nail down the details of that here first, since I'd like to make sure we can balance new features/options with simplicity of the tool.
dajabe
This might come in to play with https://github.com/evnp/tmex/issues/5
Currently every execution of the tmex command starts with
tmux new-sessionfrom what I can tell. I am basing this on what I see when using the-pflag. The output doesn't change when I set-s-ror-d, and I would have expected the flag for new-session to change at least with the-rflag.I'm running into a problem where I'm setting up a tmux session for a dev environment on a monorepo. Part of the repo has a tmex script running to launch some node processes. I'm proposing a flag that will allow the command run to substitute
new-sessionwithnew-windowallowing the tmex script to piggy back into existing tmux setup scripts.Running with the
-rflag results in the the operation trying to launch another tmux session within another session which is not ideal. The other option would be to check for the $TMUX env var and adjust the command automatically. Then a flag to force a specific behaviour if you don't it to run a new session regardless.If you like the idea I'll see if I can make a PR up for it sometime soon.