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

[GH-ISSUE #14571] No way to stop control characters output from 'ollama run' #35208

New Issue
Open
opened 2026-04-22 19:35:07 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-22 19:35:07 -05:00
Owner
Copy Link

Originally created by @peterwwillis on GitHub (Mar 3, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/14571

What is the issue?

In Ollama 0.17.5, there is no way to stop control characters from being output in the result of an ollama run ... command.

See below for method I used to test, which closes STDIN, creates a new process session with setsid(), and pipes output to cat, and then a file. Well-behaved command-line tools should not output terminal control characters in such a situation. There should either be an option to disable the control chars, or the tool should detect it does not have a tty/pty and not emit them (as they end up as garbage/noise in output when tools run them them).

I'm aware the control characters are being output to STDERR and that redirecting it to /dev/null would remove them, but 1) this is not a normal convention so normal tools would still get garbage in output, and 2) this removes error messages which tools will want to collect (such as if the 'run' command fails).

(additional notes:

  1. the website does not have documentation for the ollama run command (or any other commands)

  2. there is no documentation in the --help output or website for what the valid arguments to the --format option are, if there is one that would stop the control chars (but not be JSON):

$ ollama run --format help
Error: requires at least 1 arg(s), only received 0

$ ollama run --format help gemma2:2b foo
Error: json: error calling MarshalJSON for type json.RawMessage: invalid character 'h' looking for beginning of value

)

Relevant log output

$ env -i perl -e 'use POSIX; close STDIN; setsid(); print "Args: @ARGV\n"; exec @ARGV' ollama run --verbose gemma2:2b "Tell me about the Roman Republic" 2>&1 | cat >foo.log 2>&1

$ less foo.log
"foo.log" may be a binary file.  See it anyway?

OS

macOS

GPU

Apple

CPU

Apple

Ollama version

0.17.5

Originally created by @peterwwillis on GitHub (Mar 3, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/14571 ### What is the issue? In Ollama 0.17.5, there is no way to stop control characters from being output in the result of an `ollama run ...` command. See below for method I used to test, which closes STDIN, creates a new process session with setsid(), and pipes output to cat, and then a file. Well-behaved command-line tools should not output terminal control characters in such a situation. There should either be an option to disable the control chars, or the tool should detect it does not have a tty/pty and not emit them (as they end up as garbage/noise in output when tools run them them). I'm aware the control characters are being output to STDERR and that redirecting it to /dev/null would remove them, but 1) this is not a normal convention so normal tools would still get garbage in output, and 2) this removes error messages which tools will want to collect (such as if the 'run' command fails). --- (additional notes: 1) the website does not have documentation for the `ollama run` command (or any other commands) 2) there is no documentation in the --help output or website for what the valid arguments to the `--format` option are, if there is one that would stop the control chars (but not be JSON): ``` $ ollama run --format help Error: requires at least 1 arg(s), only received 0 $ ollama run --format help gemma2:2b foo Error: json: error calling MarshalJSON for type json.RawMessage: invalid character 'h' looking for beginning of value ``` ) ### Relevant log output ```shell $ env -i perl -e 'use POSIX; close STDIN; setsid(); print "Args: @ARGV\n"; exec @ARGV' ollama run --verbose gemma2:2b "Tell me about the Roman Republic" 2>&1 | cat >foo.log 2>&1 $ less foo.log "foo.log" may be a binary file. See it anyway? ``` ### OS macOS ### GPU Apple ### CPU Apple ### Ollama version 0.17.5
GiteaMirror added the bug label 2026-04-22 19:35:07 -05:00
GiteaMirror commented 2026-04-22 19:35:08 -05:00
Author
Owner
Copy Link

@majiayu000 commented on GitHub (Mar 6, 2026):

Hi, I traced the root cause to the progress package — the render(), Stop(), and StopAndClear() methods emit ANSI escape sequences unconditionally, regardless of whether stderr is connected to a terminal.

My proposed fix adds TTY detection in NewProgress() using term.IsTerminal() (already a dependency). When the writer is not a TTY, progress rendering and ANSI output are suppressed entirely.

This matches the behavior of tools like curl and wget which suppress progress bars when not connected to a terminal.

Happy to adjust the approach if you prefer a different direction.

<!-- gh-comment-id:4013085686 --> @majiayu000 commented on GitHub (Mar 6, 2026): Hi, I traced the root cause to the `progress` package — the `render()`, `Stop()`, and `StopAndClear()` methods emit ANSI escape sequences unconditionally, regardless of whether stderr is connected to a terminal. My proposed fix adds TTY detection in `NewProgress()` using `term.IsTerminal()` (already a dependency). When the writer is not a TTY, progress rendering and ANSI output are suppressed entirely. This matches the behavior of tools like curl and wget which suppress progress bars when not connected to a terminal. Happy to adjust the approach if you prefer a different direction.
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 bug
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#35208
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?