Closed erbridge closed 1 year ago
I'm pretty sure it's the piping that does it. Lots of tools inspect what STDOUT is, and if it's not a TTY they'll stop outputting colour codes.
I'm not sure if I can let them know spacer wants the colour codes. 🤔
fwiw, in my case for the thing I'm trying this with, I got "normal" behaviour by passing --ansi always
to docker compose
like so:
docker compose --ansi always up
Awesome, glad you found a workaround. I think most tools have some way to force ANSI colour codes.
https://unix.stackexchange.com/questions/249723/how-to-trick-a-command-into-thinking-its-output-is-going-to-a-terminal suggests some more general ways around this, but it doesn't look like there's one clear and easy solution.
If spacer
were to support this, I think it would have to be by wrapping the command rather than being piped to, e.g.: spacer --after 2 -- subcommand
.
As a fairly foolproof workaround, you can use faketty to execute piped commands in their own PTY, which will override almost any reasonable auto-color detection.
I don't plan to add support for this into spacer
at this time, and if faketty
can provide a reasonably generic workaround I'm hopeful that's enough for most people.
I'm not sure which thing is causing colour codes to get stripped out, spacer, or the command being piped into spacer, but it would be great to be able to have the source print in colour.