groff
[Top][All Lists]
Advanced

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

Re: [Groff] Re: grohtml utility programs in DESC?


From: MARSHALL Keith
Subject: Re: [Groff] Re: grohtml utility programs in DESC?
Date: Mon, 17 Nov 2003 14:47:45 +0000

>> When gs is installed on a Win32 platform, (either the GNU or the
>> AFPL version), all the components are installed into a GhostScript
>> directory, with registry entries to locate them.  There is no
>> guarantee that gswin32c.exe will be installed in a path where
>> grohtml would know to look for it -- it would be necessary for the
>> end user to add the GhostScript binary directory to his regular PATH
>> definition.
>
> I think this is the only thing we can expect, coming from a Unix
> environment.

This would seem to be a reasonable expectation, for those of us
coming from a Unix environment;  however, we also tend to expect
utilities to install their binaries into a common directory, such
as /usr/local/bin.

Unfortunately, Windows package developers don't tend to adopt such
a discipline; rather they tend to create their own isolated directory
for each individual package.  This means that the PATH becomes
horrendously long, when a large number of such utility packages are
to be made available in any given run time environment; such excessively
long PATHs necessarily result in a reduction in system performance.

IMHO, the better option is to collect copies of all the required
binaries together, in a common directory, and add that one directory
to the PATH.  Of course, it does make sense to preserve the original
name, when creating the copy;  I simply chose to rename gswin32c.exe
as gs.exe for its copy on my MSYS path, since that worked without any
need to modify the name which grohtml would search for, and thus seemed
to me to be the simplest solution to the naming conflict; (I am a strong
advocate of the KISS principle!)

> I rather prefer to use gswin32c -- the less changes the better.

I don't disagree with this, Werner; I just believe that renaming
gswin32c.exe is a simpler option.  Also, if we modify grohtml to expect
gswin32c.exe, should we also have a fall back option to try gs.exe, if
gswin32c.exe is not found?

> Any idea why gs is called gswin32c at all?  I suspect that there is a
> command/program/tool which is already called `gs'.

I don't know the historical reason for this.  There is a gs.exe already
present on my Win2000 box, but that is from the Cygwin implementation of
GhostScript; it is the executable we should be spawning, when we build
a Cygwin implementation of groff, but we definitely want to avoid it for
a MinGW build!

Best regards,
Keith.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]