bugGNU roff - Bugs: bug #60421, grog could recursively open files...

 
 

bug #60421: grog could recursively open files to infer -s

Submitter:  None
Submitted:  Tue 20 Apr 2021 05:24:05 AM UTC
   
 
Category:  Utilities Severity:  1 - Wish
Item Group:  Incorrect behaviour Status:  Need Info
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 27 Jun 2021 04:42:24 AM UTC, comment #6: 

Revise Summary to be more in line with Wish severity, expressing what is desired (or would be necessary).

G. Branden Robinson <gbranden>
Group administrator
Sun 27 Jun 2021 01:58:57 AM UTC, comment #5: 

Okay, what's going on here is pretty simple.

grog does not parse its input the way soelim(1) does, and so it does not recursively open every "sourced" file in the input stream.

If it did, it would need to keep track of such opened files, analyze them as it does the normal input stream, and see if any of them them trigger the generation of preprocessor options.

I can think of a hack to make this easier; if any ".so" requests are encountered, fork off a copy of grog to parse the input stream after piping it through soelim(1), called explicitly.  If doing so changes the inferred option list, then the input probably requires the -s flag.

But that would still be a pain and would not work when grog reads its standard input.

At the same time it is not correct to infer the "-s" option just because the .so request is used.  "-s" is only correct if sourced files need to be preprocessed.  See the soelim(1) man page.

Did a shell version of grog really solve this problem correctly?

In the short term I think it might be better just to admit in grog's man page that it is lacking in this regard, and to advise the manual execution of the above hacky procedure to determine whether -s is truly needed (when direct inspection of the sourced files is too intimidating for the user).

Looking for feedback on this.  It is not low-hanging fruit.

Thoughts?

G. Branden Robinson <gbranden>
Group administrator
Mon 07 Jun 2021 09:49:53 PM UTC, comment #4: 

Categorizing grog bugs as Utilities, per discussion.

Dave <barx>
Group Member
Sat 22 May 2021 05:35:27 PM UTC, comment #3: 

Off-list, Denis commented:

"Ditching the shell version was a bad move as the perl version was buggy.

The current version of grog, although buggy, considers more preprocessors."

Dave <barx>
Group Member
Thu 20 May 2021 07:29:37 AM UTC, comment #2: 

comment #1:

> Denis's email-list comment about this bug (http://lists.gnu.org/archive/html/groff/2021-04/msg00036.html)


The above-linked message mentions "previously sent bug fixes for the shell version," which appears to refer to the 2012 email http://lists.gnu.org/archive/html/bug-groff/2012-05/msg00000.html, containing a patch applied in commits a8f0bd9e and cfb8f134.

Dave <barx>
Group Member
Thu 20 May 2021 06:52:32 AM UTC, comment #1: 

I admit I've been baffled by the suggested fix of "go back to shell version which works," as I read this to be referring to a version of some shell (though it was unclear what control groff could have over what version of a shell anyone used).

I was finally enlightened upon finding Denis's email-list comment about this bug (http://lists.gnu.org/archive/html/groff/2021-04/msg00036.html), which clarifies that he is talking about a shell implementation (vs the current, perl, implementation) of the "grog" program.  Perhaps this was clear to everyone but me, but I offer this comment in case anyone else was confused by the suggested fix.

This /bin/sh implementation, src/roff/grog/grog.sh, was removed in 2013 in commit 86439177.  The commit log gives no explanation for this removal, merely stating that it happened (and even that none too clearly).

But on the surface it seems like a reasonable thing to do: the same program did not need to exist implemented in two different languages.  Prior to 2013 going all the way back to git's earliest records of groff 1.02, both sh and perl versions of grog were in the tree, living at the time at /etc/grog.sh and etc/grog.pl, respectively.  One of them had to go, though it would have been nice if history had recorded why grog.pl was chosen over grog.sh as the One True Grog.

grog.pl has been modified numerous times since the 2013 removal of grog.sh; thus none of these updates will be in the last existing grog.sh.  So reverting to that is pretty clearly the wrong fix (unless someone wants to do the work of integrating all those post-2013 grog.pl updates into the grog.sh code--and maybe even then, since grog.pl may have been chosen for already existing advantages over grog.sh).

Dave <barx>
Group Member
Tue 20 Apr 2021 05:24:05 AM UTC, original submission:  

GROFF VERSION: 1.22.3

MACHINE: Dell Inspiron

OS: Ubuntu 18.04

COMPILER: g++ 7.5.0

INPUT FILES: attached

COMMAND LINE: grog testgrog.n

DESCRIPTION OF INCORRECT BEHAVIOUR: Wrong output (groff testgrog.n)
instead of (groff -st testgrog.n)

SUGGESTED FIX: go back to shell version which works.

From Denis M. Wilson

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51292:  testgrog.n added by None (12B - application/octet-stream)
file #51293:  tsub1.n added by None (12B - application/octet-stream)
file #51294:  tsub2.n added by None (24B - application/octet-stream)

 

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)
  •  

    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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-27 gbranden Summarygrog does not recursively open files grog could recursively open files to infer -s
    2021-06-27 gbranden Severity3 - Normal 1 - Wish
        StatusNone Need Info
        Assigned toNone gbranden
        Summarygrog fails to infer -s and -t options grog does not recursively open files
    2021-06-07 barx CategoryCore Utilities
    2021-04-20 None Attached File- Added testgrog.n, #51292
        Attached File- Added tsub1.n, #51293
        Attached File- Added tsub2.n, #51294

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code