bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58165] test-suite: "nroff -V ..." fails for other devices than "as


From: G. Branden Robinson
Subject: [bug #58165] test-suite: "nroff -V ..." fails for other devices than "ascii"
Date: Mon, 13 Apr 2020 09:28:29 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #7, bug #58165 (project groff):


[comment #6 comment #6:]
> 
>   I looked at the issue again.
> 
> 1) unset the LESSCHARSET environmental variable in the test script.

That doesn't sound like anything that's ever been part of the test script. 
I'm the only one who's ever committed to it and I'm pretty sure.

It would be helpful if you'd try to reproduce problems against stock,
unmodified groffs when filing bugs.  Telling us which git revision you're
testing wouldn't hurt either.

>   Result: correct operation.

That's good to hear but a little puzzling. LESSCHARSET is a very distant
fallback.  For it to be consulted, all locale checks have to fail.

> 
> 2) looked at the first case test with "locale charmap" in "nroff".
> 
>   Issued "LC_ALL=C locale charmap".
> 
>   Result: ANSI_X3.4-1968

Yes, that's what you should get.
 
>   This shows that the real culprit is a missing case candidate in the
> first case test, not the LESSCHARSET, nor the result of the "locale" I
> use in the environment.
> 
>   "groff" supports four output devices, so one is missing in the first
> case test.

I don't follow any of your reasoning here.

1. When your locale is is_IS.ISO-8559-1, "locale charmap" will return
"ISO-8859-1" unless you override the command's environment, as in case 2
below.

2. When you run "LC_ALL=C locale charmap", you will always get back
ANSI_X3.4-1968".

3. You seem to have a system with a functioning locale system, so I don't see
why nroff would ever fall back to LESSCHARSET for you.  Unless you're once
again doing something you haven't disclosed, like "LESSCHARSET=latin1 LC_ALL=C
nroff".  In that scenario, nroff will attempt to use the latin1 device and it
is working exactly as documented in the man page.

I believe I've resolved the problems here with my latest commits to nroff and
its test script, but I'll give it a few minutes before resolving the ticket
because I need to catch up on mail.

>   A case of wrong conclusions, suggestions is seen in the bug
> report #58098.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58165>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]