Open pirafrank opened 1 month ago
Existing options may look confusing to some users, for example --confirm sounds as the user do need to confirm, while it means it won't be necessary. Also since version 0.3.0 the option is mutually exclusive with --interactive, which do ask the user to insert the command to be run.
Introducing --interactive
in version 0.3 is to safely remove --confirm
in the future — it's a design flaw, running a shell shouldn't be that painful.
Another limit is running commands in a shell different than /bin/sh. Power users often customize their shell environment, including using different shells (such as bash, zsh, or fish) and customizing $PATH for them. For Yazi to run shell commands in /bin/sh may turn into errors as $PATH is almost never customized there.
Sorry, no, I explained the reasoning in this PR, but I welcome any patches as long as they work with most mainstream shells (bash, zsh, fish, nushell, cmd, powershell).
Keep the --block option as-is (good for programs that behaves like git log), add another option called --blockAndWait that does what the appended ; read would do, thus keeping the output of the command run in the primary screen and Yazi in the second, waiting for the user to press return.
It's doable, but I'm a bit skeptical of its value. It seems like --blockAndWait
is longer than just ; read
, and what advantages does it have over ; read
?
Hi, sorry for late reply, back after a couple of days off.
Introducing
--interactive
in version 0.3 is to safely remove--confirm
in the future — it's a design flaw, running a shell shouldn't be that painful.
I didn't know about the future plans of refactoring shell options, but I totally agree.
Sorry, no, I explained the reasoning in this PR, but I welcome any patches as long as they work with most mainstream shells (bash, zsh, fish, nushell, cmd, powershell).
Sorry, maybe I am missing the point here but I think it's totally doable.
Vim, Neovim, and other programs gives the chance to run commands in the default shell of the user, the one from which themselves have been run. It's up to the user to write commands that work for the shell he/she configured in Yazi config. If I write a Bash command on PowerShell I do not expect it to work. Yazi should just handle the error internally not to crash and propagate it to the user for him/her to understand.
Defaulting to /bin/sh
could be a safety net here, as well, albeit only on *nix platforms.
It's doable, but I'm a bit skeptical of its value. It seems like
--blockAndWait
is longer than just; read
, and what advantages does it have over; read
?
Just my opinion. Yazi as a tool has a lot of potential now and in the future to be customised to the needs of power users alike who surely already know about subprocesses, exit codes, and more happening under the hood when a shell
command is invoked. Yet it's simple and nice looking to attract more beginner-to-medium experienced users who may not understand the 'flashing' issue it's not a real one and think it's about Yazi instead. The option would ease the onboarding and UX of those users.
Sorry, maybe I am missing the point here but I think it's totally doable
Yes, this is indeed doable, we just need to find solutions tailored for each shell, such as addressing the issue with the fish shell where $argv
includes $0
— $0
is a variable Yazi uses to store the currently hovered file, not the list of files selected by the user. We might also need to write a separate parser for PowerShell, similar to what we've done for cmd.
What I want to say is that while this would require significant effort, the benefits might not be very substantial because Yazi is more focused on implementing complex features through plugins rather than shells and I've explained why in that PR.
I can't invest too much time into this because there are other more important things to address, but I won't reject any PRs as long as they resolve these differences between shells.
Yet it's simple and nice looking to attract more beginner-to-medium experienced users who may not understand the 'flashing' issue it's not a real one and think it's about Yazi instead
Fair enough, I'll try to implement it in the future.
Adding up to this issue after discovering this nice plugin, on which I just made a PR about the read
support above. It may be a viable alternative for now I guess.
yazi --debug
outputPlease describe the problem you're trying to solve
Right now existing 'shell' configuration options in
keymap.toml
offer a way to run commands based on keymaps, which may include an explicit pre-defined command or one a user is prompted to type. Yet the following apply:--confirm
sounds as the user do need to confirm, while it means it won't be necessary. Also since version0.3.0
the option is mutually exclusive with--interactive
, which do ask the user to insert the command to be run./bin/sh
. Power users often customize their shell environment, including using different shells (such as bash, zsh, or fish) and customizing$PATH
for them. For Yazi to run shell commands in/bin/sh
may turn into errors as$PATH
is almost never customized there.--block
option to wait for a command to finish its execution, in this case Yazi will hide into a secondary screen and display the program on the main screen until it exits. Yet this pose a challenge for scripts or programs that exit successfully but do not wait for a user input, in such a case the shell will flash the output and Yazi will return to the primary screen with the user having no time to read the output. For example, the current behavior it's ok for commands likegit log
but is not forls
. A today workaround may be appending; read
to the command to run so that the output stays in place until the user presses return.Would you be willing to contribute this feature?
Describe the solution you'd like
The following changes are proposed:
--confirm
to--no-prompt
and--interactive
to--prompt
to better esplicitate which one asks the user to insert a command and which not, and to clarify that the two are mutually exclusive.yazi.toml
to specify in which shell to run commands. Run in/bin/sh
by default but let the user use an alternative non interactive shell of choice, one for example where$PATH
has been customized.--block
option as-is (good for programs that behaves likegit log
), add another option called--blockAndWait
that does what the appended; read
would do, thus keeping the output of the command run in the primary screen and Yazi in the second, waiting for the user to press return.Additional context
No response
Validations