[Top][All Lists]

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

Re: MinGW vs. c-api.test

From: Eli Zaretskii
Subject: Re: MinGW vs. c-api.test
Date: Fri, 13 Jun 2014 21:09:07 +0300

> Date: Fri, 13 Jun 2014 12:31:14 -0400
> From: Mike Gerwitz <address@hidden>
> Cc: Neil Jerram <address@hidden>, Eli Zaretskii <address@hidden>,
>       address@hidden
> My coworkers use MinGW, and it does expose [A-Z]:\ as /[a-z]/; all paths in
> MinGW are expected to be Unix-style.

They are most probably using the MSYS Bash as the shell.  They must,
because there's no decent port of Bash (or any Posix shell) as a
native Windows program.

MSYS tools exist to allow configuring and building MinGW programs
using Posix configury and Makefiles.  But MSYS is not MinGW; rather,
it is a companion to MinGW.  Some people also use the MSYS Bash as
their interactive shell, but that doesn't make that shell a MinGW

> I used the `uname` binary to determine if MinGW was being used with shell
> scripts; it returns "MINGW32_NT-6.1".

What the uname binary returns is determined at compile time (with the
exception of the OS version, which is the 6.1 part in what you show).
I have here 2 MSYS uname binaries (one that I use to build MinGW
programs, the other came with msysgit), and one MinGW uname binary.
Here's what they report _on_the_same_system_:

  MINGW32_NT-5.1 HOME-C4E4A596F7 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
  MINGW32_NT-5.1 HOME-C4E4A596F7 1.0.12(0.46/3/2) 2012-07-05 14:56 i686 unknown
  windows32 home-c4e4a596f7 2.5.1 2600 i686-pc Intel unknown MinGW

The first 2 are from MSYS uname binaries, the last one is from a
native MinGW binary.

> That said, I'm expecting that Guile's (uname) will return something wholly
> different depending on what was used to compile it!

The MinGW compiled Guile shows this:

  scheme@(guile-user)> (uname)
  $1 = #("Windows XP" "HOME-C4E4A596F7" "build 2600" "5.01 Service Pack 3" 

Which is what I expect.  I'm not aware of an MSYS build of Guile, so I
don't know what it will return.  And I don't have Cygwin here to try

Moreover, I don't quite see what the uname report has to do with the
issue at hand, which is how to use the null device portably.

> Another method I used was also checking the MSYSTEM environment
> variable, which is set to "MINGW32" on those systems.

MSYSTEM is the environment variable set by MSYS's /etc/profile file.
Its existence and value do not mean that you are in a MinGW shell.  As
I wrote above, there's no MinGW port of Bash that is bug-free enough
for it to be able to run a garden-variety configure script.  So anyone
who runs Bash on Windows is either running an MSYS Bash or a Cygwin

> All that said, on msys:
>   $ echo foo > C:\foo
>   $ cat /c/foo
>   foo
>   $ echo foo > C:\nul
>   $ cat /c/nul
>   # no output

Yes, that's MSYS for you.

reply via email to

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