Using tmux to run commands in a separate window

[joelim-work]

There are various modes for running custom shell commands, but each of them have certain limitations:

• shell-async commands (&) run in the background and does not allow for user input/output.
• shell commands ($) allows for user input/output, but also suspends the UI so that it is not visible.
• shell-pipe commands (%) is an attempt to combine the benefits of the shell-async and shell commands, but can only display a single line of output, and additionally input is line-buffered so text cannot be sent without pressing Enter.

One way to solve this problem is to enhance lf so that it can run commands inside a separate window in the UI. But I think this is not trivial to implement for a few reasons:

• The tcell library is fairly low-level and does not have the concept of creating UI widgets.
• A pty needs to be allocated to manage the new terminal session, which most likely requires an external library like pty.
• Users may request various options relating to the window such as the placement, size, borders, padding, etc..

Because of this, I do not see this kind of feature being supported natively in lf in the near foreseeable future. Such a feature may also stray from the design goal of keeping lf as a minimalistic application, which involves integration with other tools to support features instead of trying to implement everything by itself.

---

However, I recently had the idea of using tmux to create a separate 'drawer' panel on the bottom, which can serve various purposes, such as running a shell or displaying various information. Below is a sample configuration, which creates a utility command open-drawer to run various commands inside a separate window:

cmd open-drawer &{{
    tmux split-window -l 25% "$1"
}}

map w open-drawer bash
map t open-drawer top
map L open-drawer 'ls; read -n 1'

I am not completely sure how useful this kind of technique is in practice, but hopefully other people will find ways to utilize this for their own needs.

[og900aero]

I try this code, but doesnt work. Exactly nothing happend when press w, t or L.
When I try in terminal: tmux split-window -l 25% bash
I get error message: error connecting to /tmp/tmux-1000/default (No such file or directory)

I'm on Debain 12 stable with dk tiling windows manager and st terminal.

[og900aero]

I find the solution, but this method doesnt solve many problems, and for this I also need to run tmux before running lf. Then, in addition, tmux visually messes up the bottom row with its own information bar, so this is not good, at least for me.

It would be more useful if the output could be sent there in the % version, for example sudo could ask for the password there. Of course, the most perfect thing would be if a separate small window came up and you could type in there, as we say in the case of yazi program. But if this cannot be realized, then this will remain an eternal shortcoming of the lf.

[DusanLesan]

You can hide status bar in tmux.
And I do not see the issue with always having to start tmux first, If your flow demands additional windows within lf, just start lf like this: tmux new-session 'lf'

[og900aero]

When is use tmux in lfrun, then the previewer (picture, doc, xls etc) doesnt work:

#!/bin/sh
set -e

cleanup() {
    exec 3>&-
	rm "$FIFO_UEBERZUG"
}

if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ]; then
	lf "$@"
else
	[ ! -d "$HOME/.cache/lf" ] && mkdir --parents "$HOME/.cache/lf"
	export FIFO_UEBERZUG="$HOME/.cache/lf/ueberzug-$$"
	mkfifo "$FIFO_UEBERZUG"
	ueberzug layer -s <"$FIFO_UEBERZUG" -p json &
	exec 3>"$FIFO_UEBERZUG"
	trap cleanup EXIT
	tmux set -g status off
	tmux new-session 'lf' "$@" 3>&-
fi

[og900aero]

Now works preview with tmux, but I don't see why this tmux solution would be good. I use two solutions, and this tmux is better than none of them:

1. map $clear; bash
2. Since I use tiling windows manager (dk, rarely bspwm), the scratchpad function is set there. This way, I can bring up the terminal at any time (configures small size), and I can also close it in such a way that its contents are noted and the next time it is opened, it shows where I left off. So, this tmux solution does not replace the fact that if a script is waiting for input, it can be written at the bottom with %, and anything can be typed in and then accepted: for example, managing a compressed file with a password, or if it is waiting for a password due to sudo .

[DusanLesan]

This is most useful for people that want to have lf interacting with another app to get a multi-line dialog. % is not quite the solution considering it would show single line. Also scratchpad (even if people have it) might be displayed as a floating window cantered on screen even though lf might only use half or less. So my opinion is that this is perfect solution for use cases like this bulk rename in nvim:

output.mp4

[joelim-work]

@DusanLesan Thanks for your responses and support.

A quick note about the % prompt - despite its appearance and the way it provides user input/output, it is not actually a shell at all. It is actually much more closer to a text input field where you type/edit a single line, and the result is passed to a non-interactive shell to be executed. There are various features to enhance this experience, for instance limited tab completion for things like filenames/applications, and also stdout is captured and displayed to allow for simple read input prompts. But at the end of the day it will always have limitations because it is not actually a shell.

The idea of using tmux as an alternative for % is something I only thought of recently, and I decided to share it with the community. It is not intended to be a magical solution that will satisfy every user, but more of an idea that others might be inspired by, and be able to make use of. At this point, I should mention one drawback of this approach - it requires the user to know how to use tmux.

This is actually a good moment to talk about the implications of keeping the design of lf minimalistic (in the style of UNIX philosophy), as opposed to adding direct support for many features as built-ins. Having less features means having less bugs, and allows maintainers to continue focusing on what is truly important to lf, which is to manage files. This also means that users will often have to configure additional tools to work in combination with lf to fill in the gaps (e.g. image previews, anything in integrations, etc.). In addition, users may also have to be aware of UNIX-related concepts like how processes work, how environment variables work, how to write shell scripts, etc., and not everyone has the time or effort for all of this. As a result, I can see why some users might prefer a file manager that is 'batteries-included' with more features built in (I haven't used yazi very much, but it looks like a good example) as it requires minimal setup to get working. However I don't see lf going down this route, and I am probably not too interested to see that happen either.