Update of bug #60421 (project groff):
Severity: 3 - Normal => 1 - Wish
Status: None => Need Info
Assigned to: None => gbranden
Summary: grog fails to infer -s and -t options => grog does
not recursively open files
_______________________________________________________
Follow-up 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?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?60421>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
