color by default
With the attached patch, I propose to enable the colored output by
default in PG13.
For those who don't like color output, I also add support for the
environment variable NO_COLOR, which is an emerging standard for turning
off color across different software packages (https://no-color.org/).
Of course, you can also continue to use the PG_COLOR variable.
I have looked around how other packages do the automatic color
detection. It's usually a combination of mysterious termcap stuff and
slightly less mysterious matching of the TERM variable against a list of
known terminal types. I figured we can skip the termcap stuff and still
get really good coverage in practice, so that's what I did.
I have also added a documentation appendix to explain all of this.
(Perhaps we should now remove the repetitive mention of the PG_COLOR
variable in each man page, but I haven't done that in this patch.)
I'm aware of the pending patch to improve color support on Windows.
I'll check that one out as well, but it appears to be orthogonal to this
one.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Use-colors-by-default.patchtext/plain; charset=UTF-8; name=0001-Use-colors-by-default.patch; x-mac-creator=0; x-mac-type=0Download+145-1
On Tue, Dec 31, 2019 at 11:40 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
I'm aware of the pending patch to improve color support on Windows.
I'll check that one out as well, but it appears to be orthogonal to this
one.
Actually I think it would be better to rebase that patch on top of this, as
the Windows function enable_vt_mode() incorporates the logic of both
isatty() and terminal_supports_color() by enabling CMDs support of VT100
escape codes.
Regards,
Juan José Santamaría Flecha
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
regards, tom lane
On Tue, Dec 31, 2019 at 7:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
+1
Show quoted text
regards, tom lane
On 31 Dec 2019, at 14:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.FWIW, I shall be setting NO_COLOR permanently if this gets committed.
Me too.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
+1
cheers ./daniel
På tirsdag 31. desember 2019 kl. 14:35:39, skrev Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
It's easier to spot errors/warnings when they are colored/emphasized imo. Much
like colored output from grep/diff; We humans have colored vision for a reason.
--
Andreas Joseph Krogh
On 2019-Dec-31, Andreas Joseph Krogh wrote:
It's easier to spot errors/warnings when they are colored/emphasized imo. Much
like colored output from grep/diff; We humans have colored vision for a reason.
I do use color output (and find it useful), for that reason.
I'm not sure that the documentation addition properly describes the
logic to be used; if it does, I'm not sure that the logic is really what
we want. Is the logic in the docs supposed to be "last rule that
matches wins" or "first rule that matches wins"? I think that should be
explicit. Do we want to have NO_COLORS override the TERM heuristics?
(I'm pretty sure we do.) OTOH we also want PG_COLORS to override
NO_COLORS.
Per https://no-colors.org (thanks for the link) it seems pretty clear
that people who don't want colors should be already setting NO_COLORS,
and everyone would be happy. It's not just PG programs that are
colorizing stuff.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
Per https://no-colors.org (thanks for the link) it seems pretty clear
On 31/12/19 14:35, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
+1
...and Happy New Year!
/ J.L.
On 01/01/2020 02:35, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.regards, tom lane
I find coloured output very difficult to read, as the colours seem to be
chosen on the basis everyone uses white as the background colour for
terminals -- whereas I use black, as do a lot of other people.
Cheers,
Gavin
On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
I find coloured output very difficult to read, as the colours seem to be
chosen on the basis everyone uses white as the background colour for
terminals -- whereas I use black, as do a lot of other people.
I don't like colored output either.
(It is, however, probably not a surprise to anyone that I am
old-school in many regards, so how much my opinion ought to count is
debatable. I still use \pset linestyle old-ascii when I remember to
set it, use vi to edit, with hjkl rather than arrow keys, and almost
always prefer a CLI to a GUI when I have the option. I have conceded
the utility of indoor heat and plumbing, though, so maybe there's hope
for me yet.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
With the attached patch, I propose to enable the colored output by
default in PG13.FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I find color massively useful for grep and its variants, where the hit can
show up anywhere on the line. It was also kind of useful for git,
especially "git grep", but on my current system git's colorizing seems
hopelessly borked, so I had to turn it off.
But I turned PG_COLOR on and played with many commands, and must say I
don't really see much of a point. When most of these command fail, they
only generate a few lines of output, and it isn't hard to spot the error
message. When pg_restore goes wrong, you get a lot of messages but
colorizing them isn't really helpful. I don't need 'error' to show up in
red in order to know that I have a lot of errors, especially since the
lines which do report errors always have 'error' as the 2nd word on the
line, where it isn't hard to spot. If it could distinguish the important
errors from unimportant errors, that would be more helpful. But if it
could reliably do that, why print the unimportant ones at all?
It doesn't seem like this is useful enough to have it on by default, and
without it being on by default there is no point in having NO_COLOR to turn
if off. There is something to be said for going with the flow, but the
"emerging standard" seems like it has quite a bit further to emerge before
I think that would be an important reason.
Cheers,
Jeff
On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote:
On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:I find coloured output very difficult to read, as the colours seem to be
chosen on the basis everyone uses white as the background colour for
terminals -- whereas I use black, as do a lot of other people.I don't like colored output either.
I don't like colored output either. However there is an easy way to
disable that so applying this patch does not change things IMO as
anybody unhappy with colors can just disable it with a one-liner in
a bashrc or such.
--
Michael
On 06/01/2020 18:38, Michael Paquier wrote:
On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote:
On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:I find coloured output very difficult to read, as the colours seem to be
chosen on the basis everyone uses white as the background colour for
terminals -- whereas I use black, as do a lot of other people.I don't like colored output either.
I don't like colored output either. However there is an easy way to
disable that so applying this patch does not change things IMO as
anybody unhappy with colors can just disable it with a one-liner in
a bashrc or such.
--
Michael
That's kind of like using a sledgehammer to crack a nut.
The colour in grep output is often useful.
I'd like to control it per application.
Cheers,
Gavin
The patch to improve color support on Windows has been commited [1]/messages/by-id/20200302064842.GE32059@paquier.xyz, and I
would like to share some of the discussion there that might affect this
patch.
- The documentation/comments could make a better job of explaining the case
of PG_COLOR equals 'always', explicitly saying that no checks are done
about the output channel.
Aside from the decision about what the default coloring behaviour should
be, there are parts of this patch that could be applied independently, as
an improvement on the current state.
- The new function terminal_supports_color() should also apply when
PG_COLOR is 'auto', to minimize the chances of seeing escape characters in
the user terminal.
- The new entry in the documentation, specially as the PG_COLORS parameter
seems to be currently undocumented. The programs that can use PG_COLOR
would benefit from getting a link to it.
[1]: /messages/by-id/20200302064842.GE32059@paquier.xyz
/messages/by-id/20200302064842.GE32059@paquier.xyz
Regards,
Juan José Santamaría Flecha
On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
- The new entry in the documentation, specially as the PG_COLORS parameter
seems to be currently undocumented. The programs that can use PG_COLOR
would benefit from getting a link to it.
The actual problem here is that we don't have an actual centralized
place where we could put that stuff. And anything able to use this
option is basically anything using src/common/logging.c.
Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
have no actual example of how to use it, and the original thread has
zero reference to it:
/messages/by-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
And in fact, it took me a while to figure out that using it is a mix
of three keywords ("error", "warning" or "locus") separated by colons
which need to have an equal sign to the color defined. Here is for
example how to make the locus show up in yellow with errors in blue:
export PG_COLORS='error=01;34:locus=01;33'
Having to dig into the code to find out that stuff is not a good user
experience. And I found out about that only because I worked on a
patch touching this area yesterday.
--
Michael
On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan Jos� Santamar�a Flecha wrote:
- The new entry in the documentation, specially as the PG_COLORS parameter
seems to be currently undocumented. The programs that can use PG_COLOR
would benefit from getting a link to it.The actual problem here is that we don't have an actual centralized
place where we could put that stuff. And anything able to use this
option is basically anything using src/common/logging.c.Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
have no actual example of how to use it, and the original thread has
zero reference to it:
/messages/by-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.comAnd in fact, it took me a while to figure out that using it is a mix
of three keywords ("error", "warning" or "locus") separated by colons
which need to have an equal sign to the color defined. Here is for
example how to make the locus show up in yellow with errors in blue:
export PG_COLORS='error=01;34:locus=01;33'Having to dig into the code to find out that stuff is not a good user
experience. And I found out about that only because I worked on a
patch touching this area yesterday.
I can confirm there is still no mention of PG_COLORS in our
documentation.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +On Thu, Mar 19, 2020 at 10:15:57PM -0400, Bruce Momjian wrote:
On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan Jos� Santamar�a Flecha wrote:
- The new entry in the documentation, specially as the PG_COLORS parameter
seems to be currently undocumented. The programs that can use PG_COLOR
would benefit from getting a link to it.The actual problem here is that we don't have an actual centralized
place where we could put that stuff. And anything able to use this
option is basically anything using src/common/logging.c.Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we
have no actual example of how to use it, and the original thread has
zero reference to it:
/messages/by-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.comAnd in fact, it took me a while to figure out that using it is a mix
of three keywords ("error", "warning" or "locus") separated by colons
which need to have an equal sign to the color defined. Here is for
example how to make the locus show up in yellow with errors in blue:
export PG_COLORS='error=01;34:locus=01;33'Having to dig into the code to find out that stuff is not a good user
experience. And I found out about that only because I worked on a
patch touching this area yesterday.I can confirm there is still no mention of PG_COLORS in our
documentation.
My mistake, PG_COLOR (not PG_COLORS) is documented properly.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Bruce Momjian <bruce@momjian.us> writes:
I can confirm there is still no mention of PG_COLORS in our
documentation.
My mistake, PG_COLOR (not PG_COLORS) is documented properly.
Yeah, but the point is precisely that pg_logging_init()
also responds to PG_COLORS, which is not documented anywhere.
regards, tom lane
On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I can confirm there is still no mention of PG_COLORS in our
documentation.My mistake, PG_COLOR (not PG_COLORS) is documented properly.
Yeah, but the point is precisely that pg_logging_init()
also responds to PG_COLORS, which is not documented anywhere.
Oh, I thought it was a typo. OK, so it still an open item.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +