bugGNU troff - Bugs: bug #57510, not all TTY output controls...

 
 

bug #57510: not all TTY output controls simultaneously available (nroff needs -P)

Submitted by:  Dave <barx>
Submitted on:  Tue 31 Dec 2019 03:32:35 PM UTC  
 
Category:  Device - others Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Closed Planned Release:  1.22.5

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 10 Feb 2020 11:32:50 AM UTC, comment #20: 

Fixed in dd725dce808dcff643d33f180ed7ac73e32b0760.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Mon 10 Feb 2020 11:16:19 AM UTC, comment #19: 

comment #18:

> New patch looks good to me.


Thanks, Dave!

> Just two nitpicks about the nroff.1.man changes:
>
> * Is "-P post-proc-option" the best way to say that?  nroff's postprocessor will always be grotty, right?  Maybe "-P grotty-option" reinforces this more?


I think learning to associate "-P" with "(p)ostprocessor" is better pedagogy.  However, I'm emphasizing that grotty is always nroff's postprocessor in the NEWS item for this change.

> * I'd prefer to see the page explicitly state that -h and -c are respective aliases for -P-h and -P-c.  By leaving this unstated, a user unfamiliar with the history of how we got here might reasonably (and erroneously) infer that because these two options are treated specially, there must be something different about these two different ways to specify them.


That's fair.  I've added language for this as briefly as I could to the man page, and also noted it in the NEWS item.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Mon 10 Feb 2020 06:15:22 AM UTC, comment #18: 

New patch looks good to me.  Just two nitpicks about the nroff.1.man changes:

  • Is "-P post-proc-option" the best way to say that?  nroff's postprocessor will always be grotty, right?  Maybe "-P grotty-option" reinforces this more?
  • I'd prefer to see the page explicitly state that -h and -c are respective aliases for -P-h and -P-c.  By leaving this unstated, a user unfamiliar with the history of how we got here might reasonably (and erroneously) infer that because these two options are treated specially, there must be something different about these two different ways to specify them.
Dave <barx>
Sat 08 Feb 2020 11:28:36 PM UTC, comment #17: 

comment #16:

> I could also split the sets of incompatible options in the usage message as is now done in the man page's Synopsis section.


Ignore this.  I was confusedly thinking of grotty(1).

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sat 08 Feb 2020 11:23:06 PM UTC, comment #16: 

I see I neglected to update the usage message with regard to -V.

I could also split the sets of incompatible options in the usage message as is now done in the man page's Synopsis section.  I'll do that, and come up with a regression test.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sat 08 Feb 2020 11:15:09 PM UTC, comment #15: 

comment #14:

> comment #12:
> > Take 2 attached.
>
> The only attachment I can see is the original patch, file #48243, added 2020-01-18.


Sigh. It looks like I forgot it. Usually I notice that within 2 seconds after clicking "Send" or whatever.  Not...never.

Trying again.

(file #48377)

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sat 08 Feb 2020 08:17:24 PM UTC, comment #14: 

comment #12:

> Take 2 attached.


The only attachment I can see is the original patch, file #48243, added 2020-01-18.

comment #5:

> I strongly oppose deprecating -c.  As i repeatedly said
> before, i consider it superior to SGR output...


I apologize if I was unclear.  I was not suggesting making the functionality of -c (or -h) unobtainable.  But with the addition of a -P flag, -c merely becomes an alias for -P-c, and -h for -P-h.  Certainly for backward compatibility, bare -c and -h will have to be supported for some time to come.  My only question is, looking toward the (possibly distant) future, does it make sense to nudge users toward the more generic and flexible -P framework for passing all options to grotty?

> Reusing options for a different purpose isn't a particularly
> bright idea.  At least, a very long time should pass between
> deprecation and reuse.  The point of deprecating stuff isn't
> to free up namespace for reuse.  The point is to make the
> user interface smaller and simpler.


Agree with all this, which is why I tongue-in-cheekly invoked 2034 (though perhaps 14 years doesn't seem like "a very long time" to 50-year-old software).  But yes, my primary motive is to (eventually) remove the redundancy of two different mechanisms for specifying the same thing.

Dave <barx>
Mon 20 Jan 2020 06:28:38 PM UTC, comment #13: 

Forgot to mention that it passed some basic smoke tests.

cd build
make
./nroff
./nroff -V
./nroff -V -P-i
./nroff -t -man -V -P-i ./tmac/groff_man.7
./nroff -t -man -P-i ./tmac/groff_man.7
./nroff -t -man -P-i ./tmac/groff_man.7 |less -R
./nroff -c -t -man -P-i ./tmac/groff_man.7 |less -R
./nroff -c -t -man -P-i ./tmac/groff_man.7 |less
./nroff -c -t -man -P-i -V ./tmac/groff_man.7
./nroff -t -man -P-i -V ./tmac/groff_man.7

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Mon 20 Jan 2020 06:22:40 PM UTC, comment #12: 

Take 2 attached.

  • Undeprecated -c and -h.
  • Implemented -V.  Just the simple version.  Initially I considered -VV for invoking groff with -V, but groff already supports -VV meaning something else, and supporting -VVV starts to sound a little nuts to me, and in any case the parallelism is lost at that point.
  • Discarded $Popts.  You're right, it helped nothing.
  • I disagree about how to represent an option with an option argument and arity 0..n.  I think [-Popt ...] gets the idea across just fine, in parallel to [FILE ...].  Synopsis language is (almost?) isomorphic to POSIX Basic Regular Expressions.  A ... indicates an arity of >= 1 for the preceding atom, and surrounding brackets permit an arity of 0.  As you can guess I'd love to have a mathematical argument about this. >:-)
  • I have no plans to reuse nroff's -c and -h for anything, nor even any ideas for enhancements they could be attached to.
  • Pulled -mtty-char into $opts.
  • Got rid of eye-watering ${1+"$@"} construction.  This is another instance of Autoconf shell dialect.  POSIX shells should have no trouble.
  • In a subsequent commit, I'd like to more aggressively dispose of pre-POSIXisms, but here I confined my radical updates to 1995 standards only on lines I was already touching.

comment #5:

> Regarding the patch:
>
> * I strongly oppose deprecating -c.  As i repeatedly said before, i consider it superior to SGR output because it doesn't require running the pager in an insecure mode (depending on which pager mode the user picks, it may be marginally or substantially insecure).  I recommend using -c and still think it should be the default.  It is also the only output mode supported by mandoc(1), and it looks extremely unlikely that mandoc will ever support SGR.
> * I have no opinion about -h, it doesn't seem to matter much either way.
> * Adding the -P option to nroff(1) makes sense to me.
> * What's the point in adding a separate $Popts variable?  Why not just add each -P argument to $opts using a line like: opts="$opts -P$1"?
> * I believe the changes to the handling of the -c and -h options are buggy.  Either you have to leave them untouched (adding them to $opts) or you have to change the "opts=" to "Popts=" lest -c and -h suddenly clobber other options given earlier on the command line.  Also, you don't want "-c -h" to copy the previous content of $Popts to $opts twice.
> * I believe the ellipsis in "[-Popt ...]" in the usage() is incorrect.  It should just be "[-Popt]".  You can only give one argument to -P.  For example, "-P-d -o" wouldn't work.  Instead, "-P-d -P-o" would be required.
>
> The man(1) option name space is indeed crowded:  http://mandoc.bsd.lv/man/man.options.1.html
> Not sure it is wise to add more options of low usefulness and non-existent portability like the one you propose.
>
> Reusing options for a different purpose isn't a particularly bright idea.  At least, a very long time should pass between deprecation and reuse.  The point of deprecating stuff isn't to free up namespace for reuse.  The point is to make the user interface smaller and simpler.


comment #11:

> A dry-run flag for nroff sounds like a reasonable plan to me.
>
> Consulting https://mandoc.bsd.lv/man/man.options.1.html ,  i notice the -n that is often used for dry-run functionality is already taken for troff (since Version 7 AT&T UNIX) and hence also in groff and GNU nroff.
>
> I think i'd suggest using -V because that is already used for a very similar purpose in groff (since groff-0.6 (Sep 2, 1990)), does not appear to clash with anything else, and being an upper-case option, gives it relatively little prominence, which is good for this option.
>
> After printing the constructed groff command, you might even consider appending -V and then running that, too, such that the groff pipeline is also printed.  Or maybe not.  Not sure - just suggesting to think about it.  Does it add significant value?  If not, keep it minimal.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sun 19 Jan 2020 02:00:18 PM UTC, comment #11: 

A dry-run flag for nroff sounds like a reasonable plan to me.

Consulting https://mandoc.bsd.lv/man/man.options.1.html ,  i notice the -n that is often used for dry-run functionality is already taken for troff (since Version 7 AT&T UNIX) and hence also in groff and GNU nroff.

I think i'd suggest using -V because that is already used for a very similar purpose in groff (since groff-0.6 (Sep 2, 1990)), does not appear to clash with anything else, and being an upper-case option, gives it relatively little prominence, which is good for this option.

After printing the constructed groff command, you might even consider appending -V and then running that, too, such that the groff pipeline is also printed.  Or maybe not.  Not sure - just suggesting to think about it.  Does it add significant value?  If not, keep it minimal.

Ingo Schwarze <schwarze>
Project Member
Sun 19 Jan 2020 01:38:39 PM UTC, comment #10: 

Aha! Thanks, Ingo.  I was thinking only of command-line options.  An environment variable did not occur to me.

And sure enough, because of the way man-db's man calls nroff, we need to add support for -P to it for things to work.

$ MANROFFOPT=-P-i man ls

[behold unhelpful blank screen with "less" telling me I'm on document ? of ?]

man: command exited with status 1: (cd /usr/share/man && /usr/lib/man-db/zsoelim) | (cd /usr/share/man && /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /usr/share/man && preconv -e UTF-8) | (cd /usr/share/man && tbl) | (cd /usr/share/man && nroff -mandoc -rLL=143n -rLT=143n -P-i -Tutf8)

And thank you for read-teaming my clearly undercooked proposal.

I think I will leave -c and -h alone and implement a dry-run/debug flag for nroff (name TBD), wherein it just prints the groff command it has constructed.  That will be easier to regression-test and more to the point.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sun 19 Jan 2020 12:35:54 PM UTC, comment #9: 

Branden, i suspect Bjarni's cryptic allusion may be intended to refer to the (non-portable) man-db MANROFFOPT environment variable.  For example, "MANROFFOPT="-T html" man -t ls" gives me HTML output even on an old Debian GNU/Linux 8.11 (jessie).  Of course, it is indeed quite non-portable because not all man(1) implementations use any *roff(7) implementation as a formatting backend, and even a few that do may not use GNU troff (though GNU troff is dominant for that purpose nowadays, and has been for about 30 years).

Then again, this is somewhat tangential to our topic.  I believe we are discussing the maintenance of GNU troff, not of man-db.  ;-)

Ingo Schwarze <schwarze>
Project Member
Sun 19 Jan 2020 06:34:36 AM UTC, comment #8: 

comment #6:

> In this case there is no need to change "man-db",
> it already has the mechanism for that.
>
> The only change needed, is to change ones knowledge about it.


Could you be a little less coy?  I looked again at man(1) on my Debian 10-based system (buster), and do not see anything that passes arbitrary options to *roff.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sun 19 Jan 2020 02:55:42 AM UTC, comment #7: 

comment #2:

> Proposed patch is attached.
>
> Comments?
>


 I made two changes to my "test-nroff" in my "groff/build" part of my
local groff repository.

1) Added 'V' to the group of options without an argument

2) Added:

   -P*)
      opts="$opts $1" ;;

  Option 'V' shows how the pipeline looks with the '-P' option,
when "man" is used.

  I can now test the additions without any further changes.

1) test-nroff -P-i <e.g., .../man/nroff.1>

  That changed the colour for italic text from bluish (underlining) to
green (italic),
which I like better based on colour and brightness.

2) ... -P-r ... | more

  showed an error in the line break of some lines.

3) MANROFFOPT='-P-i' man nroff

  Same colour change as in case 1, as my "man" uses "test-nroff".

  To make changes permanent before I compile "groff" again,
I just have to transfer the changes to the "nroff.sh" file
(src/roff/nroff/nroff.sh),
as a new file, "test-nroff.am",
automatically creates "test-nroff" from "nroff.sh".

N.B.
  "test-groff" allows me to make changes to it (and thus "test-nroff)
without touching the installed software.

  For example add a new directory for macro files (build/s-tmac) that
can contain any version of a macro file.
I use is to test (permanently use) stripped macro files.

Bjarni Ingi Gislason <bjarniig>
Sun 19 Jan 2020 02:51:23 AM UTC, comment #6: 

comment #1:

> I noticed this, too, and it annoyed me.
>
> I also someday want to ask Colin Watson if he'd accept a patch to man-db establishing a flag there to pass options through to the *roff post-processor, just like -P.  (Unfortunately, -P is already taken in the man option namespace, and that namespace is crowded.)
>
> That way, people would be able to drive grotty exactly how they want by aliasing "man" to "man --post-processor-options=-i", for instance.


 In this case there is no need to change "man-db",
it already has the mechanism for that.

The only change needed, is to change ones knowledge about it.

Bjarni Ingi Gislason <bjarniig>
Sat 18 Jan 2020 12:34:22 PM UTC, comment #5: 

Regarding the patch:

  • I strongly oppose deprecating -c.  As i repeatedly said before, i consider it superior to SGR output because it doesn't require running the pager in an insecure mode (depending on which pager mode the user picks, it may be marginally or substantially insecure).  I recommend using -c and still think it should be the default.  It is also the only output mode supported by mandoc(1), and it looks extremely unlikely that mandoc will ever support SGR.
  • I have no opinion about -h, it doesn't seem to matter much either way.
  • Adding the -P option to nroff(1) makes sense to me.
  • What's the point in adding a separate $Popts variable?  Why not just add each -P argument to $opts using a line like: opts="$opts -P$1"?
  • I believe the changes to the handling of the -c and -h options are buggy.  Either you have to leave them untouched (adding them to $opts) or you have to change the "opts=" to "Popts=" lest -c and -h suddenly clobber other options given earlier on the command line.  Also, you don't want "-c -h" to copy the previous content of $Popts to $opts twice.
  • I believe the ellipsis in "[-Popt ...]" in the usage() is incorrect.  It should just be "[-Popt]".  You can only give one argument to -P.  For example, "-P-d -o" wouldn't work.  Instead, "-P-d -P-o" would be required.

The man(1) option name space is indeed crowded:  http://mandoc.bsd.lv/man/man.options.1.html
Not sure it is wise to add more options of low usefulness and non-existent portability like the one you propose.

Reusing options for a different purpose isn't a particularly bright idea.  At least, a very long time should pass between deprecation and reuse.  The point of deprecating stuff isn't to free up namespace for reuse.  The point is to make the user interface smaller and simpler.

Ingo Schwarze <schwarze>
Project Member
Sat 18 Jan 2020 08:38:46 AM UTC, comment #4: 

comment #3:

> Should users specifying -c or -h get a warning that these are deprecated?  It might be useful to encourage users to migrate away from them, so that someday these letters can be added to the pool of available options (for whatever new functionality nroff will require in 2034).  Or it might not matter at all.


I have no strong feelings about that.  It's easy to do if the consensus is for it.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sat 18 Jan 2020 08:06:28 AM UTC, comment #3: 

Should users specifying -c or -h get a warning that these are deprecated?  It might be useful to encourage users to migrate away from them, so that someday these letters can be added to the pool of available options (for whatever new functionality nroff will require in 2034).  Or it might not matter at all.

Dave <barx>
Sat 18 Jan 2020 07:39:54 AM UTC, comment #2: 

Proposed patch is attached.

Comments?

(file #48243)

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Sat 18 Jan 2020 05:40:07 AM UTC, comment #1: 

I noticed this, too, and it annoyed me.

I also someday want to ask Colin Watson if he'd accept a patch to man-db establishing a flag there to pass options through to the *roff post-processor, just like -P.  (Unfortunately, -P is already taken in the man option namespace, and that namespace is crowded.)

That way, people would be able to drive grotty exactly how they want by aliasing "man" to "man --post-processor-options=-i", for instance.

G. Branden Robinson <gbranden>
Project MemberIn charge of this item.
Tue 31 Dec 2019 03:32:35 PM UTC, original submission:  

For TTY output, there is no way to fully take advantage of local conditions.

In particular, the two following things cannot both be done:
1) Use information about the user's current locale
2) Use italic rendering, if available

To do (1), a user can invoke the nroff script, which contains logic to detect the user's environment (examining, for instance, the output of "locale charmap" and some $LC_* environment variables) and customize output appropriately.  To do (2), a user can invoke groff with an appropriate -T value and the -P-i option, which passes -i to the grotty postprocessor.

nroff lacks an equivalent to -P, rendering it unable to pass arbitrary options to grotty.  grotty flags such as -f, -i and -r give the user control over aspects of TTY output; these are unavailable to nroff, the tool specifically designed to generate TTY output.

This is perhaps technically a feature request rather than a bug report, but TTY output is so fundamental to the purpose of nroff that having TTY options unavailable to it seems like a basic enough design flaw to count as a bug, so I've filed it as such.

Dave <barx>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48377:  nroff_-P_take_2.diff added by gbranden (2KiB - text/x-patch)
file #48243:  nroff_P.diff added by gbranden (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-10 gbranden StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 1.22.5
    2020-02-10 gbranden StatusNeed Info => In Progress
    2020-02-08 gbranden Attached File- => Added nroff_-P_take_2.diff, #48377
    2020-01-20 gbranden StatusIn Progress => Need Info
    2020-01-18 schwarze StatusNeed Info => In Progress
    2020-01-18 gbranden Attached File- => Added nroff_P.diff, #48243
        StatusConfirmed => Need Info
    2020-01-18 gbranden StatusNone => Confirmed
        Assigned toNone => gbranden
        Summarynot all TTY output controls simultaneously available => not all TTY output controls simultaneously available (nroff needs -P)

    Back to the top


    Powered by Savane 3.5