--nocolor implies --noheaders about dstat HOT 3 CLOSED

Agreed. The rationale was that either you had a terminal that was capable of colors, escape controls (updates) and rows/columns (headers) information, or you didn't. And the --nocolor option is assuming that if you haven't got colors, you wouldn't have all the other functionality :-)

But I was completely ignoring that maybe someone would simply hate to have colors. And now that I think of it, I have not thought about color-blindness either...

If I would implement it, you would also be getting intermediate updates. Is that correct ?

from dstat.

Agreed. The rationale was that either you had a terminal that was capable of colors, escape controls (updates) and rows/columns (headers) information, or you didn't. And the --nocolor option is assuming that if you haven't got colors, you wouldn't have all the other functionality :-)

So in fact, the --nocolor option disables interactive display mode instead of just disabling colors ?

If I would implement it, you would also be getting intermediate updates. Is that correct ?

I would expect --nocolor to eliminate the colors, but not change the output in any other way. So, it would leave intermediate updates enabled. Is that what you mean ?

BTW, an alternative would be to add a '--headers' option to re-enable repetitive headers. The added benefit, is the the output of dstat can then be piped through a postprocessing stage, and modified (e.g. by computing a derived statistic) before it is printed on-screen.

from dstat.

What you expect makes total sense in hindsight, so I need to fix it. So rather than a feature, this is a bug. Let's retag :-)

If you pipe output from dstat, we don't have a terminal and so colors, intermediate updates and headers are disabled by default in this case. The problem is that --nocolor implies the same, which is incorrect.

from dstat.