Gentoo sets up colors for all kinds of applications, as grep, ls, less and for PS1, but not for man. According to the URL above, this can easily be done by setting LESS_TERMCAP variables which could be a default in Gentoo. The attached script could be included in /etc/profile.d/ Reproducible: Always Steps to Reproduce: 1. Log in 2. man gcc 3. Actual Results: See no colors. Expected Results: Some colors.
Created attachment 124238 [details] /etc/profile.d/setcolors.sh
Would be better to attach it to 07less in /etc/env.d/ I suppose. This just puts escape codes on my screen instead of the actual colours though - any other step required?
It didn't work via env.d for me either. But profile.d did fine. Can this be some kind of escaping / parsing problem when creating profile.env?
Yes, it's a bug with env-update. baselayout-2's version of env-update will work with this in alpha4, hopefully portage team can update their env-update to work too. Basically if an env.d entry value begins with $ we just add it as it stands instead of attempting to quote it.
i was poking around cygwin because it has colors enabled but it doesnt have these LESS envvars set nor does it patch less ... anyone care to investigate how it is handled there ? otherwise, adding this sort of thing to Gentoo by default sounds good (although i'd change the default color scheme to better line up with default Gentoo colors)
(In reply to comment #5) > i was poking around cygwin because it has colors enabled but it doesnt have > these LESS envvars set nor does it patch less ... anyone care to investigate > how it is handled there ? I believe they changed their "cygwin" TERMINFO file to contain the colours[1], because if I unset the TERM, the colours disappear (which they don't if I do the same thing in Gentoo with the environment variables set). I'm not too good at picking colors, so maybe you (or someone else) can propose a more Gentoo like scheme. [1] See description in http://nion.modprobe.de/blog/archives/569-colored-manpages.html
(In reply to comment #4) > baselayout-2's version of env-update will work with this in alpha4, hopefully > portage team can update their env-update to work too. Basically if an env.d > entry value begins with $ we just add it as it stands instead of attempting to > quote it. This is fixed in portage-2.1.3_rc8.
And in baselayout-2.0.0_rc1 Right, how do we want to handle this then? USE flag for less?
I guess it's a sane default to have (or does it break anything?). On the other hand, /etc/env.d is not config_protected, so users' changes would be overwritten. Is there another way than a USE flag, because I did not think USE flags are there to change the "default config" of a package. How could one easily revert the setting permanently without it being a USE flag?
(In reply to comment #9) > I guess it's a sane default to have (or does it break anything?). > On the other hand, /etc/env.d is not config_protected, so users' changes would > be overwritten. > Users can config protect /etc/env.d if they want to protect their changes. They can also just have a later file overwrite the value set by ebuilds.
users should never modify things in /etc/env.d/ these are default env vars so users are free to do the same exact thing they always do: put it in ~/.profile or whatever for your shell
hrm, the side affect here is that `env` can cause confusion as it includes all of color stuff ...
So, what's the status here? What steps are needed to implement this in baselayout or somewhere else?
the status is as in #12 ... it can be done, but it inserts colors into your environment which screws you up when doing `env` it could be circumvented with a wrapper, but that's clearly undesirable
(In reply to comment #14) > the status is as in #12 ... it can be done, but it inserts colors into your > environment which screws you up when doing `env` Would you agree that this is a bug in env? It should either reset colours in every new line or escape the characters, as bash's `set' is doing. If so, we could move the discussion upstream.
i would not say it's a bug in the `env` command ... it does not care about the content of environment variables, it merely shows you the key<->value binding you could try asking upstream about injecting a "normal color" escape sequence before each variable name, but i doubt it'll get accepted ...
Maybe I am confused and don't get the point at all but I've always had colored man pages: Resources (see /usr/share/X11/app-defaults/XTerm-color) *colorBDMode: on *colorULMode: on *colorBD: red *colorUL: green (Works with my xterm and rxvt-unicode)
rbu: so the last status on this was that putting colours in the ENV screwed up the `env` output. Perhaps pursue the terminfo changes instead?
Here's another way of doing it, maybe in safer way?, from Arch wiki (https://wiki.archlinux.org/index.php/Man_Page): man() { env \ LESS_TERMCAP_mb=$(printf "\e[1;37m") \ LESS_TERMCAP_md=$(printf "\e[1;37m") \ LESS_TERMCAP_me=$(printf "\e[0m") \ LESS_TERMCAP_se=$(printf "\e[0m") \ LESS_TERMCAP_so=$(printf "\e[1;47;30m") \ LESS_TERMCAP_ue=$(printf "\e[0m") \ LESS_TERMCAP_us=$(printf "\e[0;36m") \ man "$@" }
(In reply to comment #19) > Here's another way of doing it, maybe in safer way?, from Arch wiki > (https://wiki.archlinux.org/index.php/Man_Page): > > man() { > env \ > LESS_TERMCAP_mb=$(printf "\e[1;37m") \ > LESS_TERMCAP_md=$(printf "\e[1;37m") \ > LESS_TERMCAP_me=$(printf "\e[0m") \ > LESS_TERMCAP_se=$(printf "\e[0m") \ > LESS_TERMCAP_so=$(printf "\e[1;47;30m") \ > LESS_TERMCAP_ue=$(printf "\e[0m") \ > LESS_TERMCAP_us=$(printf "\e[0;36m") \ > man "$@" > } > As seen here: http://unix.stackexchange.com/questions/6010/colored-man-pages-not-working-on-gentoo GROFF_NO_SGR=1 may have to be added to force it to work. Personally, I'd much rather a wrapper to man that injected \m[red] in the code before shipping it off to groff, then it will JustWork the way the git man pages currently do. grep '\m\[' /usr/share/man/man1/* for a list of man-pages that already have colour support without needing anything changed.
few more reasons to not go the env route: - it puts the env in all programs, not just man - that means every time you use `less`, it changes the display, not just `man` along those lines, i don't think we want to mess with termcap. that too affects all output and not just when using man. that really only leaves the $MANPAGER route.
i've written a smaller wrapper that takes care of setting the right color variables. it does this via the MANPAGER env var. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=65f60cb497c44cc45f0e02f3661cfce3c5661e2c the man-db package has grown a USE=manpager flag and tweaked the config file so that the color shows up by default. let's see who starts complaining ;).
http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d97ae5090a07627f4dc52d52b585e5c391fcc64e
