Images with spaces in path silently failing to copy on drag and drop

[chappertron]

Hi @hakonharnes,

I've noticed there's a bug with dragging and dropping images with copy_images=true using certain terminals if the image path has spaces in.

Describe the bug

When dragging and dropping images with spaces in the file name (from finder in my case) the image fails to copy (with copy_images=true).
It does this silently without any warning. It appears the output of the cp command is not checked.

The issue seems to be related to some terminal emulators pre-escaping spaces in dragged in file names (see the results below).

This does not happen when the image path does not have spaces in.
This does not happen either if the file path is pasted in as plain text.

Debug Output

Paste: { "/Users/user/Pictures/Screenshots/Screenshot\\ 2025-05-25\\ at\\ 01.48.59.png " }
Paste: { "/Users/user/Pictures/Screenshots/Screenshot\\ 2025-05-25\\ at\\ 01.48.59.png " }
Line: /Users/ac5116/Pictures/Screenshots/Screenshot\ 2025-05-25\ at\ 01.48.59.png
Shell: /bin/zsh
Command: sh -c 'cp '\''/Users/user/Pictures/Screenshots/Screenshot\ 2025-05-25\ at\ 01.48.59.png'\'' '\''figures/test8.png'\'''
Exit code: 1
Output: cp: /Users/user/Pictures/Screenshots/Screenshot\ 2025-05-25\ at\ 01.48.59.png: No such file or directory

Other Terminals

It seems to be that the shell file is being escaped incorrectly, or perhaps even twice.
Dragging and dropping the file path in iTerm already pastes an escaped path (with backslashes in front of the spaces).
The same is true for the default macOS terminal, Wezterm and ghostty
Both Alacritty and Kitty do not pre-escape the path, and the drag and drop works as expected.
I even tried warp, but that was just straight up broken.

I can't think of an elegant way to avoid this issue.
You could remove the vim.fn.escapeshell call in util.execute, but that will probably break drag and drop for many other terminal users and could introduce security issues.

Steps to reproduce

Drag in an image with spaces in its file name and paste.
As mentioned above, this seems to be dependent on the terminal used.

Expected behaviour
For the image to be copied into the target directory when dragged into a file.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

Additional Info

• Term: iTerm
• os: macOS 14.7.6
• Neovim Version: 0.10.4
• Shell: fish (also find the same issue with zsh) (although zsh seems to be the one used for pasting)

[hakonharnes]

Thanks for reporting. Seems like some terminals already escape the file path, while others don't. This leads to double escaping, as you point out.

I see two possible solutions:

1. Detect if the path is already escaped and don't call vim.fn.shellescape in those cases.
2. Remove the pre-existing path escaping ("normalize" the path) and then use vim.fn.shellescape.

Still, we need a way to detect if the path is already escaped or not. Simply searching for the \ symbol will not work, since these are used as path separators on Windows. If I recall correctly windows supports both \ and / as path separators, so the cleanest and most consistent approach might be to normalize the path somehow...