Add copy target path command for symlinks

[vmikk]

yazi --debug output

Yazi
    Version: 26.1.4 (c9327ca8 2026-01-06)
    Debug  : true
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.92.0 (ded5c06c 2025-12-08)

Ya
    Version: 25.5.31 (b65a880 2025-05-30)

Emulator
    TERM                : Some("xterm-ghostty")
    TERM_PROGRAM        : Some("ghostty")
    TERM_PROGRAM_VERSION: Some("1.2.3-1.fc43")
    Brand.from_env      : Some(Ghostty)
    Emulator.detect     : Emulator { kind: Left(Ghostty), version: "ghostty 1.2.3-1.fc43", light: false, csi_16t: (19, 43), force_16t: false }

Adapter
    Adapter.matches    : Kgp
    Dimension.available: Dimension { rows: 35, columns: 167, width: 3190, height: 1530 }

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-0")
    DISPLAY                    : Some(":0")
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/usr/bin/zsh")
    EDITOR             : None
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None
    YAZI_ZOXIDE_OPTS   : None
    FZF_DEFAULT_OPTS   : None
    FZF_DEFAULT_COMMAND: None

Dependencies
    file          : 5.46
    ueberzugpp    : No such file or directory (os error 2)
    ffmpeg/ffprobe: 7.1.2 / 7.1.2
    pdftoppm      : 25.07.0
    magick        : 7.1.1-47
    fzf           : 0.67.0
    fd/fdfind     : No such file or directory (os error 2) / No such file or directory (os error 2)
    rg            : 15.1.0
    chafa         : No such file or directory (os error 2)
    zoxide        : 0.9.8
    7zz/7z        : 25.01 / 25.01
    resvg         : No such file or directory (os error 2)
    jq            : 1.8.1

Clipboard
    wl-copy/paste: 2.2.1 / 2.2.1
    xclip        : 0.13
    xsel         : 1.2.1

Please describe the problem you're trying to solve

Yazi currently supports copying various file path types (key combinations c + c, c + d, c + f, c + n), but lacks a way to copy the target path of symlinks. Users working with symlinks often need to access the resolved target path, especially when the symlink points to a relative path that becomes unusable when copied literally.

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

Add a new copy command c + t that copies the resolved target path of symlinks. For relative targets, resolve them against the symlink's parent directory to produce usable absolute paths. For broken symlinks, still copy the target path (even if it doesn't exist) as this might be useful.

Additional context

No response

Checklist

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

[sxyazi]

It's unclear to me:

• If you want to access a symlink, why not use the follow command directly?
  

  yazi/yazi-config/preset/keymap-default.toml

  Line 131 in c9327ca

  { on = [ "g", "f" ], run = "follow", desc = "Follow hovered symlink" },

• Your implementation always copies relative symlinks as absolute paths - what if the user wants to copy the relative path, as is?
• If a symlink is relative to a parent directory (../, ../../, etc.) rather than the current directory (./), should the path be normalized/cleaned? For example, should /a/b/c/../d become /a/b/d?
• If the symlink resides in a virtual filesystem such as SFTP, should an sftp:// prefix be added? If not, how would you distinguish between a local file and an SFTP file?

[vmikk]

Thanks! Great points.

1. I was not aware about the follow command before - that's definitely useful.
   So technically a user can do g+f then c+c.
   But copying the target path still might be useful when you don't want to change navigation context (e.g., if the target is elsewhere).

2. My initial choice mirrored the idea of c+c which returned the full path.

3. I do not have strong opinion here. Probably path normalization makes sense (e.g., turning /a/b/c/../d into /a/b/d). For my use cases just a valid (unnormalized) path is enough.

4. I haven't thought about virtual filesystems. Probably the same path representation as returned by c+c should be used for consistency.

Apart from the implementation details, I believe that, broadly speaking, having an option to copy a symlink's target path (in the c copy menu) would be quite useful. If you give the green light, I'm happy to adjust the implementation and behavior accordingly.

[sxyazi]

Thank you for the update!

2. c+c (copy file absolute path) and c+f (copy filename) are paired, because a file's relative path is just its filename. But that's not true for symlinks: a symlink can point up an arbitrary number of parent directories, not always relative to the current directory.

3. Path normalization seems to make more sense, but we need to consider cases where normalization fails e.g. how should we handle /root/../../../a? We may also want to provide an extra option allowing users to opt out of normalization, but that doesn't need to be implemented till a user requests it.

4. The problem here is that if a symlink points to a relative path on SFTP, then copying a URL like sftp://my-server/../../a doesn't make much sense because it can't be used outside its context (the CWD). For example, you can't start Yazi with yazi sftp://my-server/../../a, whereas an absolute path doesn't have that problem. This needs some more thought.

Also, have you considered implementing it as a simple plugin? Yazi exposes a link_to property, which is the file the symlink points to. Maybe doing it that way would make it quicker to trial-and-error and integrate the plugin's ideas into Yazi eventually.

[vmikk]

Thanks for the suggestion to implement this as a Lua plugin - that makes a lot of sense.
I started prototyping a plugin version and have a draft working for local files (no VFS links handled yet, and with very basic path normalization):
https://github.com/vmikk/symlink-target-path.yazi

I will probably close the PR #3520 , as the plugin should cover the task well.

[sxyazi]

Awesome, thanks for putting this together, it works great for me!

I appreciate that you started with the basic functionality instead of trying to handle every possible case up front before a real need comes.

One quick question: I noticed that for non-symlink files it falls back to the file path instead of an empty string, would that better fit your workflow? It's not a problem at all, just thought it might be worth noting on this issue for future reference :)

[vmikk]

Thanks for your kind words.

One quick question: I noticed that for non-symlink files it falls back to the file path instead of an empty string, would that better fit your workflow?

In my use case, I usually do not have a mixture of symlinks and non-symlinked files. But if I do, I thought that returning target path for every selected file would be logical.

It should be straightforward to add a config option to return paths only for symlinks. However, I'm not sure how to handle the case when multiple files selected - should empty strings be included (like blank lines) or omitted entirely?