Am 11.08.2019 um 00:29 schrieb Brian Inglis:
On 2019-08-10 03:07, Thomas Wolff wrote:
Am 09.08.2019 um 22:51 schrieb Brian Inglis:
On 2019-08-09 13:31, Thomas Wolff wrote:
Am 09.08.2019 um 20:56 schrieb Achim Gratz:
Jon Turney writes:
This gets a GTG from me.
I believe that according to our stated procedures additional approvals
are required, because this package is unique to cygwin.
I'm not sure I remember correctly from when the discussion went on the
first time, but wasn't there some mumbling about this partly going into
groff? If that's still the case, remind me what this would entail and
I'll look into it.
There are multiple ways of activating the feature (also described in the man
page).
The previous strategy placed a shell script wrapper "groff" aside groff, so the
groff script and groff.exe would coexist in /bin. This was tricky to install and
particularly it reportedly did not survive a package update of groff.
The new approach does not use this wrapper anymore. Instead it redirects nroff
to the package-supplied iroff script by configuration in /etc/man_db.conf.
How are updates to man-db, /etc/man_db.conf etc. handled?
I checked the man-db postinstall script, and it does not overwrite
man_db.conf if it exists already, so the modification will persist.
Is a permanent postinstall script provided to maintain the conf on man-db
updates?
Not needed under the observation above. If it were, how would a
permanent postinstall be deployed?
Thanks,
Thomas
There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars
(see attached - must be sourced from profile or rc) to remap bold, underline,
etc. into italic and/or colour, or whatever else you want to change, in all less
output.
So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls
should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do?
Those settings affect all *less* output, not just *man*.
Some people can't stand any colours (white on black was good enough for my
grandfather...) the same as I couldn't wait for decent fonts, graphics, and
colour support on something other than plotters, like displays and printers, and
then for files.
Options are good, to allow users to choose where and what is affected, and how.
Sorry, been messing around with colours, fonts, graphics, and SGR sequences so
much, that I can't remember what led to what. You need the reset sequences also.
Set GROFF_NO_SGR=1 to pass old bold/italic overstrikes thru for less to
colourize - looks like if GROFF_NO_SGR just exists it works:
$ LESS_TERMCAP_md=$(tput bold)$(tput setaf 4) \
LESS_TERMCAP_me=$(tput sgr0) \
LESS_TERMCAP_us=$(tput sitm)$(tput setaf 4) \
LESS_TERMCAP_ue=$(tput ritm)$(tput sgr0) \
GROFF_NO_SGR= man man
bold is also bright blue, underline is shown as italic in blue: the attached now
sets these up in the env.
Other uses of SGR sequences are in e.g.:
$ GREP_COLORS='mt=0;33;44;1;7:ln=34' grep -bnHi color ~/.bash*
which on mt matches resets SGR, then sets fg colour yellow, background blue,
enables bold, then reverses those colours, to display bold blue on bright
yellow, line numbers in green, defaulting file names to magenta, and byte counts
in blue; also e.g.:
$ \
GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'\
gcc -g -Og -Wall -Wextra -c mintty_config.c
as I run black fg text in white bg windows, and bright yellow fg warnings are
invisible; just like blue fg messages in black bg windows, most combos of
magenta and red, and many of cyan and green: those similar hues should be
unmappable pairs in any colour palette!
