bugGNU roff - Bugs: bug #52526, [gn]roff: no warning or error when...

 
 

bug #52526: [gn]roff: no warning or error when a line ends with "\{"

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Mon 27 Nov 2017 01:28:51 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Invalid
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 09 Jun 2021 03:13:22 PM UTC, comment #4: 

comment #3:

> > Is this a manifestation of bug #45502?
>
> I'm going to say no?  According to what we see there, AT&T troff has an extra-special syntax case where if there are no tokens (or spaces only?) after the conditional expression of an .if or .ie request before a newline, then the newline is ignored.
>
> This is a hypothesis.  I should fire SIMH back up and see.  Or read the V7/Heirloom source.


The above turns to be wrong--in fact, it seems to be backwards. Heirloom Doctools troff and V7 Unix troff both produce the same output for the following input.


$ cat if.roff
.if \nb
one
.nr a 1
.if !\na
two
.br
.pl \n(nlu


That output being


one two


This is what I would have expected given the documentation I just freakin' wrote not too long ago.

Imagine, then, my shock when groff itself didn't behave this way.


$ groff -Tutf8 if.roff  | od -c
0000000


And that's groff 1.22.4, not something I horked up on Git HEAD.

I'm thinking the above is indeed a manifestation of bug #45502.

I think Carsten was right, but it was hard for me to see that because he characterized the syntax used as "wrong".  It wasn't wrong, just degenerate.  He also, I feel, inaccurately characterized the specification of the control structure requests; in "traditional" troff, whitespace is optional between both the request and the conditional expression, and the conditional expression and the "body" of the if/ie.

On V7 Unix we see:


$ nroff
.nra 2
.if\na=2foobar
foobar
[65 blank lines]


Anyway, I guess the balance of the discussion should move back to bug #45502.


G. Branden Robinson <gbranden>
Group administrator
Tue 08 Jun 2021 02:13:00 AM UTC, comment #3: 

Two points I forgot to mention.

First, the ordering of the output lines is observably different.  I don't regard this as a compatibility issue.  .tm output goes to standard error and normal nroff output to standard output, and they are interleaved onto the same file descriptor by the shell.  Ordering is therefore not reliable.

Secondly...hi, Dave!

comment #1:

> Is this a manifestation of bug #45502?


I'm going to say no?  According to what we see there, AT&T troff has an extra-special syntax case where if there are no tokens (or spaces only?) after the conditional expression of an .if or .ie request before a newline, then the newline is ignored.

This is a hypothesis.  I should fire SIMH back up and see.  Or read the V7/Heirloom source.

G. Branden Robinson <gbranden>
Group administrator
Tue 08 Jun 2021 02:04:19 AM UTC, comment #2: 

I don't believe this report is correct.

groff's behavior is consistent with both Heirloom Doctools nroff and Version 7 Unix nroff.

Input:

.ie t \{
.  tm this is the t-block
.\}
.el \{
. tm this is the n-block
.\}
.pl \n(nlu


groff output:

this is the n-block


Heirloom output:


this is the n-block


AT&T output (with the whole SIMH session just for fun):

$ pdp11

PDP-11 simulator V3.8-1
sim> set cpu 11/45
Disabling XQ
sim> set tto7b
Non-existent unit
sim> set tto 7b
sim> att rl unix_v7_rl.dsk
sim> boot rl
@boot
New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)wlrl2unix
wlrl2unix not found
: rl(0,0)rl2unix
mem = 177856
# Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 06:22:30 EDT 1988

login: dmr
$ cat >52526.roff
.ie t \{
.  tm this is the t-block
.\}
.el \{
. tm this is the n-block
.\}
.pl \n(nlu
$ cat 52526.roff
.ie t \{
.  tm this is the t-block
.\}
.el \{
. tm this is the n-block
.\}
.pl \n(nlu
$ nroff 52526.roff

this is the n-block


I believe recent updates to our documentation have made this subject much clearer.


5.20.2 if-then
--------------

 -- Request: .if cond-expr anything
     Evaluate the conditional expression COND-EXPR, and if it evaluates
     true (that is, to a positive value), interpret the remainder of the
     line ANYTHING as if it were an input line.  Recall from *note
     Request and Macro Arguments:: that any number of spaces between
     arguments to requests serves only to separate them; leading spaces
     in ANYTHING are thus not seen.  ANYTHING effectively _cannot_ be
     omitted; if COND-EXPR is true and ANYTHING is empty, the newline at
     the end of the control line is interpreted as a blank input line
     (and therefore a blank text line).

          super\c
          tanker
          .nr force-word-break 1
          super\c
          .if ((\n[force-word-break] = 1) & \n[.int])
          tanker
              => supertanker super tanker

...

5.20.4 Conditional Blocks
-------------------------

 -- Escape: \{
 -- Escape: \}
     It is frequently desirable for a control structure to govern more
     than one request, call more than one macro, span more than one
     input line of text, or mix the foregoing.  The opening and closing
     brace escapes '\{' and '\}' perform such grouping.  Brace escapes
     can be used outside of control structures, but when they are they
     have no meaning and produce no output.

     '\{' should appear (after optional spaces and tabs) immediately
     subsequent to the request's conditional expression.  '\}' should
     appear on a line with other occurrences of itself as necessary to
     match '\{' escapes.  It can be preceded by a control character,
     spaces, and tabs.  Input after a '\}' escape on the same line is
     processed only if all of the preceding conditions to which the
     escapes correspond are true.  Furthermore, a '\}' closing the body
     of a 'while' request (discussed below) must be the last such escape
     on an input line.

          A
          .if 0 \{ B
          C
          D
          \}E
          F
              => A F

          N
          .if 1 \{ O
          .  if 0 \{ P
          Q
          R\} S\} T
          U
              => N O U

     The above behavior may challenge the intuition; it was implemented
     to retain compatibility with AT&T 'troff'.  For clarity, it is
     idiomatic to end input lines with '\{', followed by '\<RET>' if
     desired to prevent the newline from being interpreted as a blank
     text line, and to have nothing more than a control character,
     spaces, and tabs preceding '\}' on an input line.

          .de DEBUG
          debug =
          .ie \\$1 \{\
          ON,
          development
          \}
          .el \{\
          OFF,
          production
          \}
          version
          ..
          .DEBUG 0
          .br
          .DEBUG 1

     Try omitting the '\<RET>'s from the foregoing example and see how
     the output changes.  Remember that, as noted above, after a true
     conditional (or after the 'el' request if its counterpart 'ie'
     condition was false) the remainder of the input line is interpreted
     _as if it were on an input line by itself_.


G. Branden Robinson <gbranden>
Group administrator
Mon 07 Jun 2021 10:33:02 PM UTC, comment #1: 

Is this a manifestation of bug #45502?

Dave <barx>
Group Member
Mon 27 Nov 2017 01:28:51 AM UTC, original submission:  


  Input:

.pl 10
.ie t \{
.  tm this is the t-block
.\}
.el \{
. tm this is the n-block
.\}

  commands:

  test-groff <file> > /dev/null

  nroff -ww <file>

##

  The same results with compatibility code on (-C).

  This is not compatible with classical troff.


Bjarni Ingi Gislason <bjarniig>

 

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

Attach Files:
   
   
Comment:
   

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 gbranden (Posted a comment)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by barx
  • -email is unavailable- added by bjarniig (Submitted the item)
  •  

    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.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-08 gbranden StatusNone Invalid
        Assigned toNone gbranden
        Open/ClosedOpen Closed
    2018-06-16 barx Carbon-Copy- Added barx

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code