Similar to #827, seeing ANSI colors with --no-color #956
Loading…
x
Reference in New Issue
Block a user
No description provided.
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?
What I'm trying to do and why
Heya, I'm scripting some stuff around
info
, and when there is errors, I'm seeing a ANSI reset of\x1b[0m
instdout
output.Steps to reproduce
Run
borgmatic --no-color info --json
from a python subprocess call (expecting an error), seeing the error viastderr
(good), but also seeing a mostly emptystdout
, but with\x1b[0m
.Actual behavior
As above.
Expected behavior
No ANSI whatsoever, if using
--no-color
.Other notes / implementation ideas
No response
borgmatic version
1.9.4
borgmatic installation method
pipx
Borg version
1.4.0
Python version
3.11
Database version (if applicable)
No response
Operating system and version
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
Thanks for taking the time to file this. Unfortunately I haven't been able to get a repro thus far. Here's what I tried with both borgmatic 1.9.4 and main:
So stdout is zero bytes, meaning that there aren't any ANSI codes in it. I've also tried without redirection, and didn't see anything suspicious on the console. If you run that command, do you get a similar result? Or do you see an escape code in the output?
If you do get the same result, then can you give a little more info about your repro? What error are you getting, and what's your config file look like?
Yeah, I get the same result as you.
This is truly doing my head in; I've been changing
TERM
, settingNO_COLOR
(as I useclick
andrich
) selectively culling parts of my app, cannot work it out other than it is indeedborgmatic
outputting it -- here's anstrace
launched from within:The ANSI can clearly be seen at the end
write
ing to FD 1.I've confirmed that locally:
And now I have a fix in main! The problem was that colorama was unconditionally outputting a color reset code at exit. Incidentally, it may make sense to ditch colorama at some point: #958.
This fix will be part of the next release. Thanks again!
We were on the same page, nice one. A pleasure working with you as always Dan!
I've read the other ticket, agreed. I'd like to take a stab at that if you like? I note in there you speak of the size of
rich
, I personally don't see that as an issue (is your concern around size because you are vendoring?). Happy for me to proceed withrich
?Sorry, I just saw this after having already implemented that ticket. My apologies! I ended up just replacing colorama with a handful of color constants.. borgmatic wasn't using a lot of colorama's functionality. And yes,
rich
seemed like overkill. The size wasn't a huge issue—borgmatic itself doesn't do any vendoring even if third-party packages might—but after looking atrich
it seemed like a higher-level library than borgmatic really needed to color a couple of different log types.All good!
Released in borgmatic 1.9.5!