Update of bug #68497 (group groff):
Severity: 3 - Normal => 4 - Important
Status: None => Need Info
_______________________________________________________
Follow-up Comment #1:
> $ groff -man
> Assertion failed: context != DELIMITER_GROFF_EXPRESSION, file
> /jenkins/jobs/oi-userland/workspace/components/text/groff/groff-1.24.1/src/roff/troff/input.cpp,
> line 2887, function is_usable_as_delimiter
> groff: error: gtroff: Aborted (core dumped)
I can't reproduce this problem under GNU/Linux, and do not have access to an
OpenIndiana system upon which to test the scenario. I tried to get to the GCC
Compiler Farm's Solaris 10 and Solaris 11 hosts to test those, but the network
connection is timing out.
Does it occur when any other macro packages are loaded? When none at all are
loaded?
Try these commands:
$ groff -mdoc
$ groff -ms
$ groff -mm
$ groff -me
$ groff -mom
$ groff
This assertion is thrown only when GNU _troff_ thinks it has input to parse,
and has already read a partial escape sequence (or other delimited context,
like an output comparison operator or the argument to the `tl` request). So I
furthermore wonder if you can reproduce the problem when running GNU _troff_
directly and tell it _not_ to read any startup files.
$ gtroff -R
How do each of the foregoing commands succeed or fail?
> The problem also occurs with
> $ groff -m man
Not a surprise. If it fails with "groff -man", it should also fail with
"groff -m man", "groff -m an", and "groff -mman". This is because (1) GNU
_troff_ uses getopt_long(3), which allows zero or more spaces between an
option letter and its argument, and (2) _groff_ ships a macro file called
"man.tmac" which simply `so`urces the "real" macro file, "an.tmac". See
_groff_tmac_(5).
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68497>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
