[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#2969: zsoelim [in man] is confused by .so in macros definitions

Package: man

[This looks like a bug report I filed for soelim in groff. This is normal
because zsoelim's purpose is like soelim's, except that it should handle
compressed files gracefully. The two packages being not ]

The zsoelim program whose job is to replace .so commands by the contents
of the source file incorrectly tries to replace .so lines in the body
of a macro definition (as a side effect, it fails).

Some manual pages do have some definitions like:

	.de dI
	.so \\$1


	.de pI
	.sy includePS "\\$1" "\\$2" "\\$3" "\\$4" > /tmp/pI.tmp.
	.so /tmp/pI.tmp.
	.sy rm -f /tmp/pI.tmp.

(you get the idea) where it is difficult to replace the .so commands.
(In the particular case of the manual pages I tested, these macros are
not even used, but zsoelim still does warn about not being able to replace
the .so commands).

I suggest that such uses do only produce warning messages iff the macro
they are defined in is ever used. This needs a change in the zsoelim
program to recognize the fact that the .so is used inside a macro
definition, and then to check if that particular definition is ever used.

If the macro is effectively used, there will be a problem because
zsoelim cannot be asked to understand enough nroff to parse macro
usage and get the correct file. In this case the call will give an
incorrect document, hence in the case of man an incomplete man page.
  I see two possible ways to correct this. First, man could place in
LD_LIBRARY_PATH a version of libc that can transparently open compressed
files (zlibc), so that groff will effectively source the correct file;
in this case, no warning should be issued, but this trick is certainly
OS-specific. The second possibility would be to have a groff that could
try compressed files on a .so if the regular file cannot be found; this
would work on any system, and add a feature to groff (maybe dependent
on a command-line option?).
  Of course, one could say that such man pages should be banned. At least
I'd like not to get warnings when these macros aren't use...


Reply to: