[PR #15666] fix: strip surrounding quotes from drag-dropped file paths in interactive CLI #61952

Open
opened 2026-04-29 16:55:31 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15666
Author: @bhaveshbansal47
Created: 4/18/2026
Status: 🔄 Open

Base: mainHead: fix/interactive-quoted-file-paths


📝 Commits (1)

  • 5e1a55d fix: strip surrounding quotes from drag-dropped file paths in interactive CLI

📊 Changes

1 file changed (+14 additions, -6 deletions)

View changed files

📝 cmd/interactive.go (+14 -6)

📄 Description

Fix: strip surrounding quotes from drag-dropped file paths in interactive CLI

Problem

When a user drags and drops an image into a terminal running ollama run <model>, many terminals (zsh, fish, some GUI terminal emulators) automatically wrap the dropped path in single or double quotes — especially when the path contains spaces:

'/Users/jane/my photos/image.jpg'
"/Users/jane/my photos/image.jpg"

The previous regex only matched paths starting with /, ./, or \, so the leading quote character was silently skipped and the match began from the / inside the quotes. This worked for simple cases but was fragile: the surrounding quotes were never consumed as part of the match, which meant paths could be matched twice (once via a quoted alternative, once via the unquoted fallback) and the cleanup step in extractFileData could leave stray quote characters in the message text. Additionally, if a quote character ever ended up on a matched path before reaching os.Open, the file-not-found error would be swallowed silently (ErrNotExistcontinue), making the image appear to be ignored with no feedback.

Fix

extractFileNames — the regex now has three explicit alternatives tried left-to-right:

  1. '<path>.ext' — single-quoted path (allows unescaped spaces via [^']+?)
  2. "<path>.ext" — double-quoted path (allows unescaped spaces via [^"]+?)
  3. Original unquoted pattern ([\S\\ ]+?) for escaped-space and no-space paths

Quoted alternatives are listed first so the engine consumes the full '...' or "..." token as a single match, preventing the unquoted alternative from re-matching the inner path. After matching, strings.Trim(m, "\"'") strips any surrounding quotes before the path is returned.

extractFileData — adds strings.Trim(fp, "\"'") as a second defensive sanitization before normalizeFilePath, ensuring quotes never reach os.Open. Also adds a strings.ReplaceAll cleanup for double-quoted paths to mirror the existing single-quote cleanup.

Test plan

  • Existing TestExtractFilenames, TestExtractFileDataRemovesQuotedFilepath, and TestExtractFileDataWAV all pass unchanged
  • Manually drag a file with spaces in its path into a zsh/fish terminal running ollama run llava — image is accepted and the quoted path is removed from the message text
  • Same test with double-quoted path
  • Unquoted path with escaped spaces (e.g. /path/to/my\ image.jpg) still works
  • Unquoted path without spaces still works

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/15666 **Author:** [@bhaveshbansal47](https://github.com/bhaveshbansal47) **Created:** 4/18/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/interactive-quoted-file-paths` --- ### 📝 Commits (1) - [`5e1a55d`](https://github.com/ollama/ollama/commit/5e1a55db2dff4db46af2b587ec85b3a213bb7ad2) fix: strip surrounding quotes from drag-dropped file paths in interactive CLI ### 📊 Changes **1 file changed** (+14 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `cmd/interactive.go` (+14 -6) </details> ### 📄 Description ## Fix: strip surrounding quotes from drag-dropped file paths in interactive CLI ### Problem When a user drags and drops an image into a terminal running `ollama run <model>`, many terminals (zsh, fish, some GUI terminal emulators) automatically wrap the dropped path in single or double quotes — especially when the path contains spaces: '/Users/jane/my photos/image.jpg' "/Users/jane/my photos/image.jpg" The previous regex only matched paths starting with `/`, `./`, or `\`, so the leading quote character was silently skipped and the match began from the `/` inside the quotes. This worked for simple cases but was fragile: the surrounding quotes were never consumed as part of the match, which meant paths could be matched twice (once via a quoted alternative, once via the unquoted fallback) and the cleanup step in `extractFileData` could leave stray quote characters in the message text. Additionally, if a quote character ever ended up on a matched path before reaching `os.Open`, the file-not-found error would be swallowed silently (`ErrNotExist` → `continue`), making the image appear to be ignored with no feedback. ### Fix **`extractFileNames`** — the regex now has three explicit alternatives tried left-to-right: 1. `'<path>.ext'` — single-quoted path (allows unescaped spaces via `[^']+?`) 2. `"<path>.ext"` — double-quoted path (allows unescaped spaces via `[^"]+?`) 3. Original unquoted pattern (`[\S\\ ]+?`) for escaped-space and no-space paths Quoted alternatives are listed first so the engine consumes the full `'...'` or `"..."` token as a single match, preventing the unquoted alternative from re-matching the inner path. After matching, `strings.Trim(m, "\"'")` strips any surrounding quotes before the path is returned. **`extractFileData`** — adds `strings.Trim(fp, "\"'")` as a second defensive sanitization before `normalizeFilePath`, ensuring quotes never reach `os.Open`. Also adds a `strings.ReplaceAll` cleanup for double-quoted paths to mirror the existing single-quote cleanup. ### Test plan - [ ] Existing `TestExtractFilenames`, `TestExtractFileDataRemovesQuotedFilepath`, and `TestExtractFileDataWAV` all pass unchanged - [ ] Manually drag a file with spaces in its path into a zsh/fish terminal running `ollama run llava` — image is accepted and the quoted path is removed from the message text - [ ] Same test with double-quoted path - [ ] Unquoted path with escaped spaces (e.g. `/path/to/my\ image.jpg`) still works - [ ] Unquoted path without spaces still works --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-29 16:55:31 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#61952