Re: groff inquiry
Ian Jackson writes:
> Where programs are substantially compatible they should be made
> available by the traditional names.
I have been thinking about this a bit and I must admit that I have
warmed up to the idea of using the traditional names.
> This is because a command name identifies not a program
> (implementation) but a service (interface). One should not change the
> name of the service because it is being provided in a different way.
Being compatible is more than just having the same functionality and
input formats. It also must mean significant backward compatibility
on the command line and almost equivalent output.
soelim - compatible
nroff - compatible
refer - mostly compatible
troff - mostly compatible
neqn - terrible output :-)
eqn - output is incompatible with old eqn
pic - output is incompatible with old pic
tbl - output is incompatible with old tbl
In the last three cases, I will agree that the incompatibility is not
a huge factor since no alternative *roff exists for Linux nor is one
really expected. The incompatibility is also fairly well-documented
in the various groff manual pages.
> If we need a shell script to give the command the right option, so
> be it.
`gneqn' and `gnroff' are Bourne shell scripts provided for exactly
this purpose. However, they don't use the questionable "-C" option.
Interestingly enough, afmtodit and grog are Perl scripts. Yes, perl4
is now a required package for groff.
>> . Not a significant cost in loss of compatibility.
> This isn't true. Some programs will need to be reconfigured,
> especially Makefiles. We shouldn't force ourselves to do this
> unless there's a reason to do so.
The only instance where I think this is a significant factor is nroff.
Anything other program is bound to require changes.
>> . `groff' front-end program obviates the need for using most of
>> these programs. It is highly recommended that it be used, as
> We should provide at least all the links that are `commonly used'.
> This includes at least nroff, troff, eqn and tbl, as these are used
> for formatting manpages (the names eqn and tbl must stay the same,
> unless we want to hack up our man program to cope with adding a `g'
Well, since I am maintaining the man program (which still needs work)
for Debian, it isn't a problem. :-)
(I didn't volunteer for groff on a whim.)
> If I have a file for some random roff I'm likely to be able to format
> it unhindered using groff, provided I have a compatible macro package.
Granted, provided that you bring up the manual page.
I have been running everything with the traditional names for the last
few days. I think I might actually switch over to the traditional
names. For some reason, it feels good. Of course, this isn't final.
I guess that some of Ian's arguments must have been decent.
Now, I suppose that someone is going to complain about using the
Daniel Quinlan <email@example.com>