As an idea for a feature, it could be good if groff offered itself as a
mailcap viewer for ms and me files.  /etc/mime.types has mime types for
them, just from their .ms and .me filenames.

I suggest the lines below.  The first two would be for the existing
/usr/lib/mime/packages/groff-base.  The second two would be for the
groff package as debian/groff.mime for /usr/lib/mime/packages/groff.
Due to -TX100 gxditview in the groff package rather than groff-base.

With this it's possible to look at ms and me files as for example

    see /usr/share/doc/xterm/ctlseqs.ms.gz
    see /usr/share/doc/groff-base/meintro.me.gz

I think the "copiousoutput" lines below should confine themselves to
plain text, no ansi escapes or backspace overstrike.  You can correct me
on the best way to do that.

(May have discussed output char encoding before.  I still imagine locale
charset would be sensible, but the mailcap RFC is silent on this.)


application/x-troff-ms; /usr/bin/nroff -c -ms -Tascii | col -b; copiousoutput; description=Troff ms; priority=2
application/x-troff-me; /usr/bin/nroff -c -me -Tascii | col -b; copiousoutput; description=Troff me; priority=2

application/x-troff-ms; /usr/bin/groff -ms -TX100; test=test -n "$DISPLAY"; description=Troff ms
application/x-troff-me; /usr/bin/groff -me -TX100; test=test -n "$DISPLAY"; description=Troff me

A problem with the suggested patch is that it does not call any
preprocessors.

The grog(1) command, part of groff, might prove helpful for figuring out
an appropriate (partial) command line for the mailcap.

For generality, the mm and mom macro packages should be supported too.

I was going to say man(1), too, but it already has a mailcap entry.

However,

$ see /usr/share/man/man1/dash.1.gz
groff: gxditview: Signal 31 (core dumped)
/usr/bin/man: command exited with status 2: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -TX100 -X
Warning: program returned non-zero exit code #3

Hmmm...guess I know what I'm doing tonight.

Regards,
Branden

The SEGV appears to be a red herring.

I can repro the problem with see(1), as noted earlier in the bug
history, but not by calling the equivalent command directly.

$ zcat /usr/share/man/man1/dash.1.gz | /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -TX100 -X

...that works fine.

The backtrace looks stack-smashy...

$ gdb $(which gxditview) core
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gxditview...Reading symbols from /usr/lib/debug/.build-id/9e/20ed945f94fbf369c57d3787a014be3ad1312f.debug...done.
done.
[New LWP 15694]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `gxditview -printCommand gxditview -'.
Program terminated with signal SIGSYS, Bad system call.
#0  0x00007fe16b258ac7 in socket () at ../sysdeps/unix/syscall-template.S:78
78      ../sysdeps/unix/syscall-template.S: No such file or directory.
##(gdb) bt
#0  0x00007fe16b258ac7 in socket () at ../sysdeps/unix/syscall-template.S:78
#1  0x00007fe16acfb31d in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fe16acfb7f0 in xcb_connect_to_display_with_auth_info () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fe16b4e6db2 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x0000000000000000 in ?? ()
##(gdb) quit

...but I have a hunch that there isn't a real smash going on here, but
rather man(1)'s security sandbox putting a stop to some subset of all
this mad piping and X display connecting (which, indeed, involves a
socket-opening operation, as we can observe in the backtrace).

I feel sure that Colin can shed light on this.

In the meantime I don't think the original report will have a solution
that is baked until my earlier points about preprocessor detection are
addressed.  A crude solution would be to unconditionally run all the
classic preprocessors with "groff -R -e -p -t", but to that I would
raise the esoteric technical objection that doing so feels grody.

Regards,
Branden

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

Hmm.  Doesn't happen for me in i386 groff 1.22.4-5 and not particularly
current "testing".

I don't recognise that among typical problems ...

Yes.  At the time I don't think I thought about that, and was probably
only looking at a few documents not needing it.

I see "groffer" does many things.  I might try likely mailcap lines
using it.  It has a lot of options, but I'd think something pure-groff
(like gxditview when under X).  A user can easily copy and adapt for
personal preference.

(I think it'll want to be told "groffer -ms ..." for the relevant mime
types, as its content guessing is all very nice, but when we have the
right info eh.  That would include a -mom mime type filename .mom I
think which you mentioned before.)

I wrote:

I tried the mailcap lines below.  Intended to be "works everywhere"
level, so don't try to divine user preferences or do anything fragile
with character sets or predict $PAGER capability.  The user can copy to
~/.mailcap and adapt (that being entirely normal to select mail type
viewing preferences ...).

The X form gets a warning from grog for me, but I think is either its
fault or the way groffer runs it.


# groffer looks in the input for needed preprocessors (eg. tbl).
# --mode=X uses gxditview which is included in the groff package.
# groffer has other mode options to easily run other graphics viewers.
# -TX100 anticipates a 100dpi screen.  Can -TX75 if desired.
application/x-troff-ms; groffer --mode=X -TX100 -ms; test=test -n "$DISPLAY"; description=Troff ms
application/x-troff-me; groffer --mode=X -TX100 -me; test=test -n "$DISPLAY"; description=Troff me
#
# -Tascii output for maximum portability.
# -P -c is option -c to grotty for no SGR escapes (but still backspacing).
# col -b collapses backspacing to plain text.
# Both SGR and backspacing are undesirable for output to a file or an
# unknown viewer (such as a mail reader).
application/x-troff-ms; groffer --mode=text -Tascii -P -c -ms '%s' | col -b; copiousoutput; description=Troff ms; priority=2
application/x-troff-me; groffer --mode=text -Tascii -P -c -me '%s' | col -b; copiousoutput; description=Troff me; priority=2

reassign 769626 groff
retitle 769626 groff: want mailcap entries for .ms and .me files
thanks

Since the ms(7) and me(7) macro packages are not shipped in groff-base,
but in groff, these mailcap entries, if ever created, should be provided
in a file /usr/lib/mime/packages/groff in the "groff" package.

Regards,
Branden

Just an FYI.

The forthcoming groff 1.24.0's new `-S` option semantics should be
helpful for this sort of thing.

NEWS:

...
*  troff now recognizes an -S option, which "locks" safer mode,
   rejecting any subsequent specification of -U on the command line with
   an error diagnostic.
...
*  groff now passes the -S option to pic and troff if it is specified.
...
[pic]
*  The -S option now "locks" safer mode, rejecting any subsequent
   specification of -U on the command line with an error diagnostic.

This way even if some mailcappish interface to running shell commands
on untrusted documents permits those documents to influence how the
command-line arguments are populated (which seems dangerous but might
make sense in some scenarios; I'm no mailcap expert), by specifying the
command as "groff -S" instead of simply "groff", you can jam safer mode
on and break off the handle.

I'm hoping to tag groff 1.24.0.rc1 any day now.  I just need my
"Automated Upload Registration" credentials to issue.[1]

Regards,
Branden

[1] https://www.gnu.org/prep/maintain/maintain.html#Automated-Upload-Registration