Re: [Groff] Detection of PATH_SEPARATOR in configure

[Keith Marshall]

Shame on you, Jeff.  You hijacked Anton's thread on upper case handling,
to ask this completely unrelated question.  Now, when I find a few
moments to respond, I have to remember which thread you hijacked,
because ThunderBird has buried your original query in a collapsed
thread, where I can't readily see it.

Please, always start a new thread to introduce a new topic; never reply
to an existing thread, and change the subject, unless your new topic is
derived from the original.  I've deliberately broken threading here, to
give this topic its own thread.

On 25/11/11 03:14, Jeff Conrad wrote:
> From time to time, I've built groff using Microsoft Visual C/C++ and
> the MKS Toolkit.  The MKS environment provides most of the necessary
> Unix-like utilities without much diddling, but not without a few
> quirks.
> 
> One quirk makes it impossible for configure to detect the path
> separator.  With the MKS Toolkit (I'm using the current version 9.4),
> the test for PATH_SEPARATOR fails because
> 
>    PATH='/bin:/bin' sh -c:
> 
> succeeds because of a quirky way in which MKS handles pathnames.  It's
> easy enough to call configure with something like
> 
>    PATH_SEPARATOR=';' configure

It would be better to express this as

   configure PATH_SEPARATOR=';'

> If it is known that a particular "os" (e.g., mks) has a semicolon
> for the path separator, it may make sense to just set it.  I also
> assume that if PATH contains a semicolon, the semicolon is the path
> separator is a semicolon, so again it may make sense to just set it
> without further ado.  If neither of these tests is conclusive, the
> current test could be done, giving something like
> 
>    if test "${PATH_SEPARATOR+set}" != set; then
>        case $ac_canonical_build in
>        *-*-mks)
>            PATH_SEPARATOR=';' ;;
>        esac
>    fi

I wonder if pushing this into configure is the best way forward; is this
not, perhaps, an issue which we could better handle within groff's own
arch/misc/shdeps.sh?

In a later follow-up, you went on to say:
> James K. Lowden wrote:
>> I think your plan is reasonable.
>> 
>> The alternative would be to push on configure.guess and assume the
>> path separator for any form of Windows is a semicolon.  I'm not sure
>> that's more correct, though.
> 
> This won't always work.  MinGW uses a colon for the path separator, ...

This isn't strictly correct.  From a pedantic perspective, MinGW is a
natively hosted port of GCC to MS-Windows, no more, no less.  As such,
it doesn't make any direct reference to *any* path separator, and it's
indirect references are restricted to path searches, such as on %PATH%,
when invoking system services, (primarily DLL loading or creation of
sub-processes); in these contexts, the path separator is just what
native MS-Windows expects -- the semicolon.

Now, from a less pedantic perspective, I suspect that you really mean
the MSYS shell environment, which is offered by MinGW.org to complement
the MinGW compiler suite.  This is a light-weight fork of cygwin-1.3,
providing a minimal POSIX emulation layer on MS-Windows, which has been
adapted for better integration with native applications suites than
cygwin itself supports.  One of its principal adaptations is that, while
it does use the colon as a path separator when running on the POSIX side
of the fence, it transliterates path lists automatically, substituting
semicolon as path separator, any time when it hands a path list over the
fence to a native application, (including MinGW).

> ... and MKS provides the option to do so.

If it does so in any fashion which resembles the MSYS technique[*], then
shdeps.sh surely would be the appropriate place to address this issue;
it was created specifically to deal with the requirement for colon as
path separator within shell scripts, (which in groff's case are always
in Bourne shell syntax), while requiring semicolon as path separator
within executables compiled to native MS-Windows code, (as both MSVC and
MinGW produce).

[*] If MKS doesn't adopt this technique, how then does it resolve the
dichotomy that Bourne shell scripts interpret semicolon as a command
separator, while MS-Windows wants it to represent a path separator?  The
two interpretations are distinct, and incompatible.

-- 
Regards,
Keith.