Closed 0n-s closed 1 month ago
Yes, that is expected behavior. --color auto
is the default value, so the absence of the flag is the same thing as passing --color auto
.
There would have to be two different values for --color
, one which supports env variables and one which ignores them. Otherwise, if you were to supply any --color
flat in a config file, you could never make it respect the env vars again from within cli.
I would propose a new option --color auto_no_env
for this
Also note that theres a difference between --color always
and --color no_color
. In both cases it will use terminal sequences, but only in the first will it output color sequences as well...
when using auto
, if TERM
is set to dumb
, it will not use any terminal seqnences, then if NO_COLOR
is set it will use terminal sequences but output no color, and otherwise use all sequences.
Should a new option like that respect TERM
or not in this case? I think this is quite a difficult thing to decide
Should a new option like that respect
TERM
or not in this case? I think this is quite a difficult thing to decide
AFAIK TERM
should always be respected if the output is a terminal (i.e. isatty()
or equivalent). TERM
is just not a preference of the user, it is simply a pointer to the capabilities of the terminal set up by the terminal itself. It's not really meant to be overridden.
EDIT: for this reason:
I would propose a new option
--color auto_no_env
for this
I would suggest naming the value to be something like tty
or the like. It clearly specifies how it works: color if outputting to a terminal, no color if not. Environment variables are not necessarily user configuration, & TERM
most certainly is not. :)
Alternatively, most programs often initialize parameters like this to a NULL
or -1
value, with a separate auto
value that has the behavior described above (i.e. just isatty()
). This essentially differentiates between "respect system defaults & use in appropriate contexts if allowed by them" & "user told us to use color for this program if appropriate" (again, this means passing the isatty()
& ncurses has_colors()
[1] checks). But I can see that breaking backwards compatibility; not sure how much of a concern that is for...color output.
[1]: this is basically the more correct equivalent to the TERM=dumb
check that handles a few corner cases.
So I now propose the following change:
--color <stream>:auto-tty
: Determine if terminal sequences are supported by the <stream>
; if so enable terminal sequences AND color--color <stream>:no_color-tty
: Determine if terminal sequences are supported by <stream>
; if so enable terminal sequences but disable colorLet me know what you think, I have a PR ready to go
That seems sound, yes. Thanks!
For anyone wondering how the policies work in detail now, heres a guide. TERM
is True
if the TERM
variable is not set to dumb
, the stream is not piped and, on Windows only, VT sequences could be activated. NO_COLOR
is True
if the variable is nonempty
DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE
Checklist
Provide a description that is worded well enough to be understood
yt-dlp respects the
NO_COLOR
standard for disabling terminal color output by default. However, passing--color auto
on the command line does not override it.Passing
--color auto
explicitly should overrideNO_COLOR
, which merely specifies a default.--color always
is unideal since it means color codes are enabled even when stdout isn't a terminal.Provide verbose output that clearly demonstrates the problem
yt-dlp -vU <your command line>
)'verbose': True
toYoutubeDL
params instead[debug] Command-line config
) and insert it belowComplete Verbose Output