bugGNU roff - Bugs: bug #60672, troff: No warning about ".el...

 
 

bug #60672: troff: No warning about ".el \{"

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Tue 25 May 2021 07:23:28 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Warning/Suspicious behaviour Status:  Invalid
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 26 May 2021 06:03:37 AM UTC, comment #3: 

Quoting verbatim stuff angered Savannah.  Let's try that again.

Hi Bjarni,

Thanks for the report, but I'm afraid it's invalid.

original submission:

> Subject: troff: No warning about ".el \{"
>
>   Example:
> printf '.pl 20v
> .nr i 1
> .if i=1 \{
> .  nop
> .\}
> .ie i=0 \{
> . nop
> .\}
> .el \{
> . nop
> .\}' | test-groff -z


The above is valid input.  The \{ escape begins a scope for the preceding .if, .el, .ie, or .while request, and the very first thing it does in its scope is put a newline on the input stream.

Usually, that's not what people really want, so we encourage the '\{\newline' syntax as an idiom.

But, occasionally, it might be desired.

My new man(7) blank line macro just tracked down such a case in gpinyin(1).  But the line numbers were way off because I had a tbl(1) table inside an .ie, and thus tbl(1) was powerless to restore them.  That's something I should add to the tbl(1) man page, I reckon.

> troff: backtrace: file '<standard input>':3
> troff: <standard input>:3: warning: missing closing delimiter in
> conditional expression (got newline)
> troff: backtrace: file '<standard input>':6
> troff: <standard input>:6: warning: missing closing delimiter in
> conditional expression (got newline)


You got these diagnostics because you have apparently misunderstood how to perform an arithmetic comparison in *roff.  You cannot compare a bare register name to anything--you have to interpolate it first.

Instead of


.if i=1 i equals one


try


.if \ni=1 i equals one


and I think you'll be happier.  What is happening is that GNU troff(1) is interpreting 'i' as the opening delimiter of a "string" comparison (really, a formatted output comparison) operation.  (Heirloom Doctools troff does the same, but issues no diagnostics.)

In Heirloom, you do have to wrap the arithmetic comparison in parentheses, even if it has no internal whitespace.


.if (\ni=1) .tm i really does equal one


But as noted above, this is not necessary in groff.  I would recommend the parentheses as good style nevertheless.

> N.B.
>
>   .if ... \{
>
> did not work in an HP operation system.


Without seeing more, like what was in the "...", I cannot advise whether HP's implementation was normative per CSTR #54.

G. Branden Robinson <gbranden>
Group administrator
Wed 26 May 2021 06:02:20 AM UTC, comment #2: 

Hi Bjarni,

Thanks for the report, but I'm afraid it's invalid.

original submission:

> Subject: troff: No warning about ".el \{"
>
>   Example:


> printf '.pl 20v
> .nr i 1
> .if i=1 \{
> .  nop
> .\}
> .ie i=0 \{
> . nop
> .\}
> .el \{
> . nop
> .\}' | test-groff -z

The above is valid input.  The \{ escape begins a scope for the preceding .if, .el, .ie, or .while request, and the very first thing it does in its scope is put a newline on the input stream.

_Usually_, that's not what people really want, so we encourage the '\{\newline' syntax as an idiom.

But, occasionally, it might be desired.

My new man(7) blank line macro just tracked down such a case in gpinyin(1).  But the line numbers were way off because I had a tbl(1) table inside an .ie, and thus tbl(1) was powerless to restore them.  That's something I should add to the tbl(1) man page, I reckon.



> troff: backtrace: file '<standard input>':3
> troff: <standard input>:3: warning: missing closing delimiter in
> conditional expression (got newline)
> troff: backtrace: file '<standard input>':6
> troff: <standard input>:6: warning: missing closing delimiter in
> conditional expression (got newline)

You got these diagnostics because you have apparently misunderstood how to perform an arithmetic comparison in *roff.  You cannot compare a bare register name to anything--you have to _interpolate_ it first.

Instead of

+verbatim+
.if i=1 i equals one


try


.if \ni=1 i equals one


and I think you'll be happier.  What is happening is that GNU troff(1) is interpreting 'i' as the opening delimiter of a "string" comparison (really, a formatted output comparison) operation.  (Heirloom Doctools troff does the same, but issues no diagnostics.)

In Heirloom, you do have to wrap the arithmetic comparison in parentheses, even if it has no internal whitespace.


.if (\ni=1) .tm i really does equal one


But as noted above, this is not necessary in groff.  I would recommend the parentheses as good style nevertheless.

> N.B.
>
>   .if ... \{
>
> did not work in an HP operation system.


Without seeing more, like what was in the "...", I cannot advise whether HP's implementation was normative per CSTR #54.

G. Branden Robinson <gbranden>
Group administrator
Tue 25 May 2021 10:36:42 PM UTC, comment #1: 

original submission:

>   Related reports are #59434, #45502, and #60260.


Making those clickable: bug #59434, bug #45502, bug #60260

Dave <barx>
Group Member
Tue 25 May 2021 07:23:28 PM UTC, original submission:  

Subject: troff: No warning about ".el \{"

  Example:

printf '.pl 20v
.nr i 1
.if i=1 \{
.  nop
.\}
.ie i=0 \{
. nop
.\}
.el \{
. nop
.\}' | test-groff -z

  Shows:

troff: backtrace: file '<standard input>':3
troff: <standard input>:3: warning: missing closing delimiter in
conditional expression (got newline)
troff: backtrace: file '<standard input>':6
troff: <standard input>:6: warning: missing closing delimiter in
conditional expression (got newline)

  Related reports are #59434, #45502, and #60260.

N.B.

  .if ... \{

did not work in an HP operation system.

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 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-05-26 gbranden StatusNone Invalid
        Assigned toNone gbranden
        Open/ClosedOpen Closed
    2021-05-25 barx Item GroupNone Warning/Suspicious behaviour

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code