[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
program.
> 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"
"i686")
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
that.
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
Bash.
> 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.
- Re: MinGW vs. c-api.test, (continued)
- Re: MinGW vs. c-api.test, Ludovic Courtès, 2014/06/12
- Re: MinGW vs. c-api.test, Eli Zaretskii, 2014/06/12
- Re: MinGW vs. c-api.test, Ludovic Courtès, 2014/06/12
- Re: MinGW vs. c-api.test, Eli Zaretskii, 2014/06/12
- Re: MinGW vs. c-api.test, Ludovic Courtès, 2014/06/12
- Re: MinGW vs. c-api.test, Neil Jerram, 2014/06/13
- Re: MinGW vs. c-api.test, Ludovic Courtès, 2014/06/13
- Re: MinGW vs. c-api.test, Eli Zaretskii, 2014/06/13
- Re: MinGW vs. c-api.test, Neil Jerram, 2014/06/13
- Re: MinGW vs. c-api.test, Mike Gerwitz, 2014/06/13
- Re: MinGW vs. c-api.test,
Eli Zaretskii <=
Windows file name separators, Ludovic Courtès, 2014/06/09