bugDatabase-driven manual pager suite - Bugs: bug #25648, groff/nroff argument redux


bug #25648: groff/nroff argument redux

Submitter:  None
Submitted:  Thu 19 Feb 2009 09:24:37 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Thu 19 Feb 2009 11:02:09 PM UTC, comment #5: 

Might be worth-while to explain it somewhere, or at least point to the "grotty" man page.

I think the site-tmac change is probably the way to go regarding this, the more I think about it (after remember we ALREADY mess with that file)

Aaron Griffin <phrakture>
Thu 19 Feb 2009 10:58:11 PM UTC, comment #4: 

Well, no, I just meant that if you're prepared to change the defaults in a package of man-db then you might as well change them in a package of groff; and when you do it in groff, it's easier for users to override back if they preferred the original behaviour. GROFF_NO_SGR to GROFF_SGR is a fairly obvious transformation, whereas if you did it in man you'd have to invent another different name. Basically, I dislike layering configuration on top of configuration rather than just changing the configuration at its source.

I'm not sure I see the argument about end-user ease here, to be honest. You're already talking about a bunch of really very obscure environment variables that nobody could possibly guess. Since you have to document them anyway, what's one more? Or, if you're setting them by default somewhere, why not just set another one there?

Of course I have no problem if you want to change the "DEFINE nroff" line in your man-db configuration - that's what it's there for. I just feel that if a distribution wants to change groff's default behaviour for manual pages then the best way to do that is to change groff's default behaviour directly, as I've done in Debian, rather than to change it in man-db. Does that make sense?

I'd certainly take a documentation patch to explain all this somewhere in man-db's documentation.

Colin Watson <cjwatson>
Group administrator
Thu 19 Feb 2009 10:43:07 PM UTC, comment #3: 

Thanks for the followup, I figured this was slightly outside the scope of man-db.
The discrepancy in the default args was what originally made me post here regarding the groff issue, the -Tutf8 thing was more an afterthought.

So, to be clear - you are against the default -c argument because environment variables can be used? The only reason I think this is not the case is that most end users don't know a thing about groff, so the process to figure out that the discrepancy comes from groff's color output would be long and arduous.

Modifying the site tmac seems a little cleaner, though, and I will look into this - we already make some character translations in the default Arch Linux groff package (for things like curly-quotes and emdashes and whatnot... characters that are not keyboard chars and can't be searched for)

Aaron Griffin <phrakture>
Thu 19 Feb 2009 10:27:31 PM UTC, comment #2: 

The termcap settings you show configure less to emit colour escapes in response to things like intensity changes. I imagine that the reason this doesn't work in the configuration you describe is as follows: when groff is in SGR mode (no -c, etc.), it emits its own ANSI escapes; the -R option to less tells it to pass these straight through to the terminal. The LESS_TERMCAP_* environment variable almost certainly only take effect when less is emitting its own escape sequences in response to the old-style bold/underline sequences ('c BACKSPACE c' or '_ BACKSPACE c'). I don't see how this could possibly work given the combination of groff in SGR mode and 'less -R', unless less started deconstructing the input on the way through and guessing which termcap escapes should be used - which is, I think, expressly contrary to the documentation of -R.

This is really more a matter of groff's default configuration than man-db's default configuration, I feel. For instance, Debian's groff package puts this in /etc/groff/man.local and /etc/groff/mdoc.local (on other systems you might need to put these in /usr/share/groff/site-tmac/ or similar):

.if n \{\
.  \" Debian: Disable the use of SGR (ANSI colour) escape sequences by
.  \" grotty.
.  if '\V[GROFF_SGR]'' \
.    output x X tty: sgr 0

This has the effect of inverting groff's default behaviour as documented in grotty(1), so that instead of being able to set GROFF_NO_SGR=1 to turn off SGR escapes, they're turned off by default and you can set GROFF_SGR=1 to turn them back on.

No matter which way round the default is, though, this environment-based system seems like a fairly reasonable way to configure what you want. If you're already setting a bunch of LESS_TERMCAP_* environment variables to change less' behaviour, then setting GROFF_NO_SGR=1 as well seems like no big deal. I think I prefer this to changing man-db's defaults.

As for -Tutf8, this is a very complex area. -Tutf8 is in fact used by default in very many circumstances; for languages that are basically ASCII or ISO-8859-1, you should always find that -Tutf8 is used provided that you are using a UTF-8 locale.

However, for other languages the situation can be more complex. With versions of groff before 1.20, groff is essentially incapable of taking input in other than ISO-8859-1 (well, there were some special-case ways to approximate it, but not in any way that man-db could reasonably make use of), unless you used the Debian multibyte patch. If you were using that patch, then it was possible to more or less cope by telling groff that it needs to emit the same encoding as it got in, using -Tascii8. This isn't typographically sound, which is why it never made it upstream - groff has no idea what the characters actually are if you do that - but it was a viable stopgap measure for a wide variety of languages for some time. -Tutf8 was no good here because, while it produces UTF-8 output, it expected ISO-8859-1 input.

With groff 1.20, we have the preconv preprocessor, which converts text in any encoding you like into groff's Unicode escape syntax, thus allowing it to be understood by the groff core. Indeed, in that case, man-db will just use -Tutf8, and if necessary stick an iconv pipe on the end to convert to the encoding specified by your locale.

In short: this is a complicated area to get right and it's a serious mistake to just hardcode a single output device (a mistake that the man package commits, but nevertheless that doesn't mean I want to duplicate its mistake!). In order to determine why you aren't getting -Tutf8 and whether this is the right thing or not, I'd need to see the output of man with the --debug option.

Colin Watson <cjwatson>
Group administrator
Thu 19 Feb 2009 09:45:28 PM UTC, comment #1: 

Hmmm, I am looking into this still, and it appears that it's SUPPOSED to work without -c as long as less is called with -R. Can you get less to colorize man pages at all, without the following:

    export LESS_TERMCAP_mb=$'\E[01;31m'
    export LESS_TERMCAP_md=$'\E[01;31m'
    export LESS_TERMCAP_me=$'\E[0m'
    export LESS_TERMCAP_se=$'\E[0m'
    export LESS_TERMCAP_so=$'\E[01;44;33m'
    export LESS_TERMCAP_ue=$'\E[0m'
    export LESS_TERMCAP_us=$'\E[01;32m'

With those set, and the -c argument passed to groff/nroff, it works fine. But according to all the docs, it should work with those unset, no -c, and -R passed to less

Aaron Griffin <phrakture>
Thu 19 Feb 2009 09:24:37 PM UTC, original submission:  

The default groff and nroff calls could use some tweaks.

First off, the -c flag was the default with 'man', and disables "color output". I'm not 100% clear on what this means, as groff is difficult enough to understand as it is - but I am aware of the symptoms. Without the -c flag, less cannot colorize man pages via environment variables (LESS_TERMCAP_*) with this on.

Secondly, I have a feeling -Tutf8 might be a good option too, by default. This last one just seems nice, but I'm not clear on the consequences.

- Aaron Griffin



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by cjwatson (Posted a comment)
  • -email is unavailable- added by phrakture (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-9c15.
    Corresponding source code