github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #10333] CLI: image path not recognized correctly #32547

New Issue
Open
opened 2026-04-22 13:55:51 -05:00 by GiteaMirror · 15 comments
GiteaMirror commented 2026-04-22 13:55:51 -05:00
Owner
Copy Link

Originally created by @mchiang0610 on GitHub (Apr 18, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/10333

What is the issue?

Sometimes when dragging an image in the CLI, the file path is not properly recognized.

Example:

ollama@ollamas-computer % ollama run gemma3:27b
>>> /Users/ollama/Library/Mobile\ Documents/com\~apple\~CloudDocs/screenshots/CleanShot\ 2025-04-17\ at\ 21.26.40@2x.png 
Okay, I understand you're still referencing the same image file path. Unfortunately, I *still* cannot access files on your computer. My 
inability to view the image hasn't changed.  I'm an AI model and operate only with the text input you provide.

**To reiterate, please provide me with the *content* of the image.**  You'll need to:

1. **Describe the image to me.** Tell me what you see.
2. **Copy and paste any text from the image.**  This is the most helpful thing you^C

Relevant log output

OS

No response

GPU

No response

CPU

No response

Ollama version

0.6.5

Originally created by @mchiang0610 on GitHub (Apr 18, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/10333 ### What is the issue? Sometimes when dragging an image in the CLI, the file path is not properly recognized. Example: ``` ollama@ollamas-computer % ollama run gemma3:27b >>> /Users/ollama/Library/Mobile\ Documents/com\~apple\~CloudDocs/screenshots/CleanShot\ 2025-04-17\ at\ 21.26.40@2x.png Okay, I understand you're still referencing the same image file path. Unfortunately, I *still* cannot access files on your computer. My inability to view the image hasn't changed. I'm an AI model and operate only with the text input you provide. **To reiterate, please provide me with the *content* of the image.** You'll need to: 1. **Describe the image to me.** Tell me what you see. 2. **Copy and paste any text from the image.** This is the most helpful thing you^C ``` ### Relevant log output ```shell ``` ### OS _No response_ ### GPU _No response_ ### CPU _No response_ ### Ollama version 0.6.5
GiteaMirror added the good first issue label 2026-04-22 13:55:51 -05:00
GiteaMirror commented 2026-04-22 13:55:54 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Apr 18, 2025):

Related: #9979

<!-- gh-comment-id:2814807506 --> @rick-github commented on GitHub (Apr 18, 2025): Related: #9979
GiteaMirror commented 2026-04-22 13:55:55 -05:00
Author
Owner
Copy Link

@greengrass821 commented on GitHub (Apr 18, 2025):

Hey @mchiang0610 , I am unable to reproduce the bug myself, can you describe more about the bug. like for which type of filepaths its not working

<!-- gh-comment-id:2815502246 --> @greengrass821 commented on GitHub (Apr 18, 2025): Hey @mchiang0610 , I am unable to reproduce the bug myself, can you describe more about the bug. like for which type of filepaths its not working
GiteaMirror commented 2026-04-22 13:55:56 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Apr 18, 2025):

The backslash escaping of '~' is not handled correctly.

>>> ./filename\ with\ ~.jpg
Added image './filename with ~.jpg'
That's an absolutely adorable puppy! It looks like a little Shiba Inu, with its characteristic curled tail and alert expression. The red collar and bell add to its charm.  It's sitting patiently on a stone
step.  What a sweet little guy!

>>> ./filename\ with\ \~.jpg
Okay, let's tackle this file path issue. You've provided: `./filename\ with\ \~.jpg`

This is a common problem when copying and pasting file paths, especially when dealing with spaces or special characters.
<!-- gh-comment-id:2815533614 --> @rick-github commented on GitHub (Apr 18, 2025): The backslash escaping of '~' is not handled correctly. ``` >>> ./filename\ with\ ~.jpg Added image './filename with ~.jpg' That's an absolutely adorable puppy! It looks like a little Shiba Inu, with its characteristic curled tail and alert expression. The red collar and bell add to its charm. It's sitting patiently on a stone step. What a sweet little guy! >>> ./filename\ with\ \~.jpg Okay, let's tackle this file path issue. You've provided: `./filename\ with\ \~.jpg` This is a common problem when copying and pasting file paths, especially when dealing with spaces or special characters. ```
GiteaMirror commented 2026-04-22 13:55:57 -05:00
Author
Owner
Copy Link

@praneshsharma10 commented on GitHub (Apr 19, 2025):

hey @mchiang0610 @rick-github , I've addressed the issue in the PR , please review it.

<!-- gh-comment-id:2816727701 --> @praneshsharma10 commented on GitHub (Apr 19, 2025): hey @mchiang0610 @rick-github , I've addressed the issue in the PR , please review it.
GiteaMirror commented 2026-04-22 13:55:58 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Apr 20, 2025):

Dragging and dropping an image with an embedded single quote also fails on Linux. The behaviour might be different for MacOS since from Michael's earlier example, the path is not enclosed in quotes.

$ ollama run gemma3
>>> '/home/rick/filename with '\''.jpg' 
Okay, let's break down that file path:

*   **`/home/rick/`**: This is the root directory of the user "rick" on the system.  It's a standard Linux/Unix directory.
*   **`filename`**: This is the name of the file itself.  It's what you're calling the file.
*   **`with '\'`.jpg`**: This part specifies the file extension. The single quote (`'`) is used to escape the single quote character within the filename.  
The `.jpg` indicates that the file is a JPEG image.

**In essence, the full path represents a file named "filename" located within the "rick" user's home directory, and the file is a JPEG image.**

**Example:**

If the file was actually named "my_image.jpg", the full path would be: `/home/rick/my_image.jpg`

**Important Note:**  The single quote is often used to handle filenames that contain spaces or special characters.  It's a way to ensure the shell 
interprets the entire filename correctly.
<!-- gh-comment-id:2817135734 --> @rick-github commented on GitHub (Apr 20, 2025): Dragging and dropping an image with an embedded single quote also fails on Linux. The behaviour might be different for MacOS since from Michael's earlier example, the path is not enclosed in quotes. ``` $ ollama run gemma3 >>> '/home/rick/filename with '\''.jpg' Okay, let's break down that file path: * **`/home/rick/`**: This is the root directory of the user "rick" on the system. It's a standard Linux/Unix directory. * **`filename`**: This is the name of the file itself. It's what you're calling the file. * **`with '\'`.jpg`**: This part specifies the file extension. The single quote (`'`) is used to escape the single quote character within the filename. The `.jpg` indicates that the file is a JPEG image. **In essence, the full path represents a file named "filename" located within the "rick" user's home directory, and the file is a JPEG image.** **Example:** If the file was actually named "my_image.jpg", the full path would be: `/home/rick/my_image.jpg` **Important Note:** The single quote is often used to handle filenames that contain spaces or special characters. It's a way to ensure the shell interprets the entire filename correctly. ```
GiteaMirror commented 2026-04-22 13:55:59 -05:00
Author
Owner
Copy Link

@Rahuldrabit commented on GitHub (Jun 26, 2025):

I want to work in this issue

<!-- gh-comment-id:3008359949 --> @Rahuldrabit commented on GitHub (Jun 26, 2025): I want to work in this issue
GiteaMirror commented 2026-04-22 13:56:00 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Jun 26, 2025):

The original issue, handling an escaped tilde, is resolved. Dragging and dropping a file with an embedded single quote is still not handled properly.

<!-- gh-comment-id:3008407696 --> @rick-github commented on GitHub (Jun 26, 2025): The original issue, handling an escaped tilde, is resolved. Dragging and dropping a file with an embedded single quote is still not handled properly.
GiteaMirror commented 2026-04-22 13:56:00 -05:00
Author
Owner
Copy Link

@gee-coder commented on GitHub (Jul 4, 2025):

The original issue, handling an escaped tilde, is resolved. Dragging and dropping a file with an embedded single quote is still not handled properly.

Hello, I tried both 'and' single quotes without any reproduction issues. Could you please elaborate on this

Image

<!-- gh-comment-id:3034319941 --> @gee-coder commented on GitHub (Jul 4, 2025): > The original issue, handling an escaped tilde, is resolved. Dragging and dropping a file with an embedded single quote is still not handled properly. Hello, I tried both 'and' single quotes without any reproduction issues. Could you please elaborate on this ![Image](https://github.com/user-attachments/assets/9eadf62e-8b30-4a08-a4b9-d960722db5e9)
GiteaMirror commented 2026-04-22 13:56:01 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Jul 4, 2025):

https://github.com/ollama/ollama/issues/10333#issuecomment-2817135734

<!-- gh-comment-id:3035714965 --> @rick-github commented on GitHub (Jul 4, 2025): https://github.com/ollama/ollama/issues/10333#issuecomment-2817135734
GiteaMirror commented 2026-04-22 13:56:02 -05:00
Author
Owner
Copy Link

@caetano-dev commented on GitHub (Jul 18, 2025):

I've tested this functionality on both macOS and Linux. I can confirm it works as expected on macOS but fails on Linux. I have submitted #11472 to address the issue.

<!-- gh-comment-id:3091209466 --> @caetano-dev commented on GitHub (Jul 18, 2025): I've tested this functionality on both macOS and Linux. I can confirm it works as expected on macOS but fails on Linux. I have submitted [#11472](https://github.com/ollama/ollama/pull/11472) to address the issue.
GiteaMirror commented 2026-04-22 13:56:03 -05:00
Author
Owner
Copy Link

@finepro7 commented on GitHub (Jul 29, 2025):

hey @mchiang0610 can i work on this issue ?

<!-- gh-comment-id:3133705192 --> @finepro7 commented on GitHub (Jul 29, 2025): hey @mchiang0610 can i work on this issue ?
GiteaMirror commented 2026-04-22 13:56:03 -05:00
Author
Owner
Copy Link

@satvikpanchal commented on GitHub (Aug 28, 2025):

Can I work on this?

<!-- gh-comment-id:3234587837 --> @satvikpanchal commented on GitHub (Aug 28, 2025): Can I work on this?
GiteaMirror commented 2026-04-22 13:56:04 -05:00
Author
Owner
Copy Link

@tysoncung commented on GitHub (Dec 3, 2025):

I'm interested in working on this issue. Could you provide more context about what you're looking for? Any additional details about requirements or constraints would be helpful.

<!-- gh-comment-id:3604922520 --> @tysoncung commented on GitHub (Dec 3, 2025): I'm interested in working on this issue. Could you provide more context about what you're looking for? Any additional details about requirements or constraints would be helpful.
GiteaMirror commented 2026-04-22 13:56:04 -05:00
Author
Owner
Copy Link

@KhushAhuja commented on GitHub (Jan 12, 2026):

Hi @rick-github

I've been investigating this issue and noticed that the current approach involves manually patching individual escape characters.
I tested this locally on mac and found that the current normalizeFilePath logic still results in a silent failure for standard POSIX characters that aren't in the list.

  1. I created a file with mixed special characters: touch 'test_!_"image".jpg'
  2. I dragged it into the CLI while running moondream.
  3. The shell escaped it correctly (.../test_!_"image".jpg), but the CLI failed to process the path.
  4. Result: The prompt reset without loading the image or showing an error message.

Proposal: Instead of maintaining a manual list of replacement rules, I propose implementing a robust shell tokenizer (using a standard library approach). This would handle all quoting and escaping rules generically and prevent similar issues in the future.
I have a solution in mind and would be happy to submit a PR if you are open to this approach.

<!-- gh-comment-id:3739788072 --> @KhushAhuja commented on GitHub (Jan 12, 2026): Hi @rick-github I've been investigating this issue and noticed that the current approach involves manually patching individual escape characters. I tested this locally on mac and found that the current `normalizeFilePath` logic still results in a silent failure for standard POSIX characters that aren't in the list. 1. I created a file with mixed special characters: touch 'test_!_"image".jpg' 2. I dragged it into the CLI while running moondream. 3. The shell escaped it correctly (.../test_\!_\"image\".jpg), but the CLI failed to process the path. 4. Result: The prompt reset without loading the image or showing an error message. Proposal: Instead of maintaining a manual list of replacement rules, I propose implementing a robust shell tokenizer (using a standard library approach). This would handle all quoting and escaping rules generically and prevent similar issues in the future. I have a solution in mind and would be happy to submit a PR if you are open to this approach.
GiteaMirror commented 2026-04-22 13:56:07 -05:00
Author
Owner
Copy Link

@KhushAhuja commented on GitHub (Jan 14, 2026):

I've opened a PR to fix this. It switches to a standard shell tokenizer (google/shlex) to correctly handle quoted paths, exclamation marks, and other edge cases on all platforms. PR: #13718

<!-- gh-comment-id:3751118641 --> @KhushAhuja commented on GitHub (Jan 14, 2026): I've opened a PR to fix this. It switches to a standard shell tokenizer (google/shlex) to correctly handle quoted paths, exclamation marks, and other edge cases on all platforms. PR: #13718
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#32547
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?