[Groff] MSYS Shell -- Path Separator Nuisances

[Keith Marshall]

Work we did recently, to establish the appropriate OS dependent path 
separator character, has introduced three minor problems when building groff 
using MSYS/MinGW, and when running it under the MSYS shell. All three are 
related to the way in which path name variables, in the exported environment, 
must be represented in the native Windows runtime environment, in which the 
groff applications execute, and the [different] representation used in the 
MSYS shell and MinGW implementation of GNU make.

In the runtime environment, all paths are represented in the native Windows 
format (although forward slashes are accepted, where backslashes are normally 
used), and semicolons separate the components of a search path. Thus, we 
would have a path such as:

        PATH="c:/msys/bin;c:/msys/local/bin;c:/winnt/system"

However, the MSYS shell, (and MinGW's GNU make), use an entirely POSIX 
syntax, with the semicolon acting as a command separator, and this same path 
represented in the shell's environment, using a colon as the search path 
component separator, i.e.:

        PATH="/c/msys/bin:/c/msys/local/bin:/c/winnt/system"

The difference between these is reconciled by the shell itself, which 
converts *every* variable in the exported environment, which has a syntax 
resembling a single POSIX path name or a POSIX search path, to its 
corresponding Windows form.

The three problems I have observed are:

1. In src/doc/Makefile.sub, GROFF_BIN_PATH is constructed using semicolons,
   where the MinGW implementation requires colons.

2. In contrib/mom/Makefile.sub, the same problem arises with a similar
   definition of GROFF_BIN_PATH.

3. In src/roff/nroff/nroff.sh, GROFF_BIN_PATH is set to the BINDIR string, 
   set at configure time, which for MinGW has got to be in Windows format. 
   This is then prepended to the shell's own $PATH, using a semicolon as the 
   separator, when running groff; the semicolon here is seen as a command 
   separator, truncating the $PATH to just $GROFF_BIN_PATH, and the original 
   $PATH, prefixed to the following groff command, causes a syntax error.

Problems 1 and 2 are easily fixed, by simply always using a colon as the path 
separator, in these two makefiles. However, if we simply do this, how will 
other shells used with Windows cope with the change? Will we break the make 
process with MKS or DJGPP shells? Does anyone know of other shells we need to 
accommodate?

The nroff problem is somewhat more complex, but also quite easy to fix. In 
this case, the solution will, I think, be rather shell specific: the use of 
'/d' to represent 'd:' is, AFAIK, unique to the MSYS shell. I can progress a 
solution which will support both MSYS and Cygwin shells; it would be good if 
users of other shells could assist in adding support for their chosen one.

Best regards,
Keith.