Alternative for shell placeholders

[past-gen]

yazi --debug output

Yazi
    Version: 26.1.22 (24c6041 2026-01-27)
    Debug  : false
    Triple : x86_64-pc-windows-msvc (windows-x86_64)
    Rustc  : 1.93.0 (254b5960 2026-01-19)

Ya
    Version: 26.1.22 (24c6041 2026-01-27)

Config
    Init             : C:\Users\Admin\AppData\Roaming\yazi\config\init.lua (6049 chars)
    Yazi             : C:\Users\Admin\AppData\Roaming\yazi\config\yazi.toml (9635 chars)
    Keymap           : C:\Users\Admin\AppData\Roaming\yazi\config\keymap.toml (27884 chars)
    Theme            : C:\Users\Admin\AppData\Roaming\yazi\config\theme.toml (41069 chars)
    VFS              : C:\Users\Admin\AppData\Roaming\yazi\config\vfs.toml (The system cannot find the file specified. (os error 2))
    Package          : C:\Users\Admin\AppData\Roaming\yazi\config\package.toml (2660 chars)
    Dark/light flavor: "" / ""

Emulator
    TERM                : Some("wezterm")
    TERM_PROGRAM        : Some("WezTerm")
    TERM_PROGRAM_VERSION: Some("20251025-070338-b6e75fd7")
    Brand.from_env      : Some(WezTerm)
    Emulator.detect     : Emulator { kind: Left(WezTerm), version: "WezTerm 20251025-070338-b6e75fd7", light: false, csi_16t: (9, 20), force_16t: true }

Adapter
    Adapter.matches    : Iip
    Dimension.available: Dimension { rows: 37, columns: 151, width: 0, height: 0 }

Desktop
    XDG_SESSION_TYPE           : None
    WAYLAND_DISPLAY            : None
    DISPLAY                    : None
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("X:\\Apps\\Portable\\.cli\\nu.exe")
    EDITOR             : Some("X:/Apps/Portable/.cli/mc.exe")
    VISUAL             : Some("X:/Apps/Portable/Sublime/sublime_text.exe")
    YAZI_FILE_ONE      : Some("X:\\Apps\\.System\\GnuWin32\\bin\\file.exe")
    YAZI_CONFIG_HOME   : None
    YAZI_ZOXIDE_OPTS   : None
    FZF_DEFAULT_OPTS   : None
    FZF_DEFAULT_COMMAND: None

Text Opener
    default     : Some(OpenerRule { run: "set YaziS=%s && nu --no-std-lib -c \"%YaziS% | save -f %d1/env.text\"", block: false, orphan: false, desc: "[Test] Env", for: None, spread: true })
    block-create: Some(OpenerRule { run: "mc %s", block: true, orphan: false, desc: "Micro", for: None, spread: true })
    block-rename: Some(OpenerRule { run: "mc %s", block: true, orphan: false, desc: "Micro", for: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : program not found
    tmux build flags   : enable-sixel=Unknown
    ZELLIJ_SESSION_NAME: None
    Zellij version     : program not found

Dependencies
    file          : ExitStatus(ExitStatus(1)), "X:\\Apps\\.System\\GnuWin32\\bin\\file.exe-5.03\r\nmagic file from X:\\Apps\\.System\\GnuWin32/share/misc/magic\r\n"
    ueberzugpp    : program not found
    ffmpeg/ffprobe: ffmpeg version N-120352-gda18c2a373-20250722 Copyright (c) 2000-2025 the FFmpeg developers / ffprobe version N-120352-gda18c2a373-20250722 Copyright (c) 2007-2025 the FFmpeg developers
    pdftoppm      : program not found
    magick        : 7.1.2-13
    fzf           : 0.64.0
    fd/fdfind     : 10.2.0 / program not found
    rg            : 14.1.1
    chafa         : program not found
    zoxide        : 0.9.8
    7zz/7z        : program not found / 25.01
    resvg         : program not found
    jq            : 1.8.1

Clipboard
    wl-copy/paste: program not found / program not found
    xclip        : program not found
    xsel         : program not found

Routine
    `file -bL --mime-type`:

Please describe the problem you're trying to solve

Following that line of thought #3626 , where @sxyazi helped me realise that the actual escaping logic has little to do with the described issue, I came up with a more practical and concise solution that eliminates the need for it altogether.

The issue at hand:

• nu -c "action %s1 | save -f %d1"
  With the placeholder being part of an existing quoted sequence, any additional formatting that Yazi may, or may not, apply would break the "top-level" command formatting, as the user has likely initially written it with all necessary formatting in mind.
• command $s1 >> %d1/log/goo.die 2>> "%d1/error log/bad.die"
  Assuming that %d1 has spaces in it, the result would be something like \"'\"escaped path\"'/error log/bad.die\" or similar gibberish.
• the length of the shell command itself isn't limitless, if my memory serves me right, so depending on how lengthy its final version is going to be, command may not be able to run at all.
• ...

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

As an alternative to "hot replacement" at the shell command formatting stage, add the required values to the environment and allow the scripts/apps to access them at the execution stage instead.

This way, depending on preference, one can write custom handlers or use local existing scripts without worrying about the correct escaping, formatting, and whatnots. Without any need of .lua plugins as well.

With Nushell in my case , nu -c "[ %s ] | process somehow | par-each { do something }" turns into either:

• nu --config ~/.nu/yazi.nu -c yazi-specific-action-handler, where all required data acquired and handled internally
• nu -c "any common action $env.YA_s1 | save -f $'($env.YA_d1)/formatted/h o w e/v.er'", where it's internally interpreted

---

From Yazi perspective - an additional parameter env wherever run is used, like opener or hotkey events ( would be useful for custom-shell.yazi I think ), that would be either:

• a boolean value, to expose all shell's placeholders to ENV as variables
• compound set of all required placeholder names to extend ENV with

---

While it technically can be done by spamming set var=%... into run command, it'd cause unnecessary complication, and as mentioned, the shell command's length isn't limitless. So delegating this task to Yazi internals seems like solid idea.

Additional context

No response

Checklist

• I have searched the existing issues/discussions
• The latest nightly build doesn't already have this feature

[hankertrix]

Correct me if I’m wrong, but isn’t this just bringing back the previous version of shell parameters with $0, $1, and $@ for Unix and %0, %1, and %* for Windows?

I also faced this issue since I make use of shell parameter expansions for some of my openers, but I don’t think it’s too difficult to just use a set variable command to set the variable to the passed path and then manipulate it afterwards, which is what I’m currently doing for the openers that require it.

[past-gen]

Correct me if I’m wrong, but isn’t this just bringing back the previous version of shell parameters with $0, $1, and $@ for Unix and %0, %1, and %* for Windows?

@hankertrix , correcting you: my idea is to completely eliminate the need of %... parameters in the runner command and expose only required ones to external interpreters or apps, since they have all have access to ENV anyway. Internally.

Did you miss that part?

With Nushell in my case , nu -c "[ %s ] | process somehow | par-each { do something }" turns into either:

• nu --config ~/.nu/yazi.nu -c yazi-specific-action-handler, where all required data acquired and handled internally
• nu -c "any common action $env.YA_s1 | save -f $'($env.YA_d1)/formatted/h o w e/v.er'", where it's internally interpreted

---

I don’t think it’s too difficult to just use a set variable command to set the variable to the passed path and then manipulate it afterwards

Why complicate something when it can be made easier? It still requires the fully expanded value(s) to be present in the shell command before execution begins, which is not practical.

Also, Windows enforces 'em length limitations of 8,191 and 260 characters for the cmd shell and fs path respectively. Do the maths and tell me how many paths you can include in one shell command, when, let's say, we have 10000 entries from search result, for example. Now divide that number by two, assuming that we potentially need to process the input from %s and %d separately.

A bit exaggerated, of course, yet not impossible.

[hankertrix]

Correct me if I’m wrong, but isn’t this just bringing back the previous version of shell parameters with $0, $1, and $@ for Unix and %0, %1, and %* for Windows?

@hankertrix , correcting you: my idea is to completely eliminate the need of %... parameters in the runner command and expose only required ones to external interpreters or apps, since they have all have access to ENV anyway. Internally.

Did you miss that part?

With Nushell in my case , nu -c "[ %s ] | process somehow | par-each { do something }" turns into either:

• nu --config ~/.nu/yazi.nu -c yazi-specific-action-handler, where all required data acquired and handled internally
• nu -c "any common action $env.YA_s1 | save -f $'($env.YA_d1)/formatted/h o w e/v.er'", where it's internally interpreted

In Nushell this works, but what about other shells? Bash and zsh environment variables are just regular shell variables. It’d be equivalent to passing $0, $@, just with a longer name like $YA_s1. It makes no difference and only increases verbosity. Not everyone uses Nushell.

Why complicate something when it can be made easier? It still requires the fully expanded value(s) to be present in the shell command before execution begins, which is not practical.

I’m pretty sure @sxyazi has given you plenty of explanation as to why the shell parameters have been switched to what they are now, which are mainly for security concerns (RCEs), as the shell escaping isn’t quite sufficient.

[past-gen]

In Nushell this works, but what about other shells?

@hankertrix ...and that's why I used the word "alternative" and not "replacement", like in "additional way to do this, that can be useful in a particular scenario".

Is that another example of my poor choice of words?

---

From Yazi perspective - an additional parameter env wherever run is used, like opener or hotkey events ( would be useful for custom-shell.yazi I think ), that would be either:

• a boolean value, to expose all shell's placeholders to ENV as variables
• compound set of all required placeholder names to extend ENV with

Here I was pointing out that it shouldn't become the default way of handling things, but rather a solution to be used as an alternative, only when specifically requested. Well, at least tried to.

---

It’d be equivalent to passing $0, $@, just with a longer name like $YA_s1
It makes no difference and only increases verbosity

I care not about the variable naming, they can stay the same, makes no difference.

My point is to make them available in the environment before the runner command's executed in shell, or constructed even. Not turning parameters into literal paths in command's body, but leave them as they are for shell to interpret them at execution phase as it sees fit, capiche? That is the difference.

Or don't use any at all, like in that example:

nu --config ~/.nu/yazi.nu -c yazi-specific-action-handler

• no raw paths, meaning no need to escape anything
• as all paths exist as strings in an environment beforehand and Yazi defines the variable naming, format and content, there' no security risks?
• be it part of top-level, or any subsequent chain of calls it'd work identically, cmd can access if with %var% syntax, nushell or powershell with $env, unix shells in their own way. Pipe it, print it, parse it, read it, save it, do whatever, all are happy.
• more compact runner commands, mean there is no risk of reaching the OS-specific length limit

But, since this may not be suitable for different shells/environments/users/workflows/whatnots, I just ask to add it as an optional feature, as it'd solve my problems, and may be useful for someone else.

[past-gen]

@sxyazi, your thoughts on all that, if you may?

Am I asking for something unreasonable here?
If not, whether it is technically feasible and implementation can be expected in the near future, or should I look for and resort to a local solution, whatever that may be?..

[hankertrix]

Here I was pointing out that it shouldn't become the default way of handling things, but rather a solution to be used as an alternative, only when specifically requested. Well, at least tried to.

I think this will add quite a bit of maintenance burden since there are now two ways to do shell parameter passing. It's probably a better idea to just use either one or the other.

I'm also not sure if this implementation would be a lot of work, since Yazi will have to call all the supported shells' set variable command to set the environment variables before executing the run command, unless Rust has a safe add to environment function that does this easily.

To me it seems reasonable, since it is just setting environment variables in the shell to the escaped string for use in commands so that the path doesn't get substitute directly into the command.

Either way, it is up to @sxyazi.