Re: [Mingw-msys] Re: Description of MSYS in forthcoming C++ Cookbook, by O'Reilly

[Greg C. <chi...@co...>]

On 2005-8-4 20:14 UTC, Jonathan Turkanis wrote:
> Greg Chicares wrote:
> 
>>On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote:
>>
>>>Cygwin is an ambitious project to produce a Linux-like environment
>>>hosted by Windows; a remarkable assortment of GNU utilities are
>>>available as part of the Cygwin distribution.
>>
>>Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh,
>>ash, and I forget what others, just as one example.
> 
> It's a GNU bash, though, isn't it?
> 
>   $ help
>   GNU bash, version 2.04.0(1)-release (i686-pc-msys)

Sure. I'm saying that cygwin goes beyond
  "a remarkable assortment of GNU utilities"
                              ^^^
and provides lots of non-GNU utilities as well. Taking shells as
just one example, I can get by with bash, but I prefer zsh for
everyday work, and I use ash to test script portability.

But your statement is completely true.

>>>While one of the main goals of Cygwin is to
>>>facilitate porting GNU applications to Windows, even if you are not
>>>UNIX developer you may soon come to regard the Cygwin tools as
>>>indispensable.
>>
>>There I actually wouldn't agree.
[snip]
> 
> I think you misunderstood me. I'm not comparing Cygwin to MSYS here
[...]
> Please let me know what part of the text wasn't clear.

OK, I thought you were comparing Cygwin to MSYS.

>>>Among other things, MinGW includes a runtime environment, a
[...]
> 
>>I'm not sure what you mean by "MinGW includes a runtime environment":
>>do you mean bash, or perhaps the posix emulator underlying it? I'd
>>consider those parts of MSYS instead.
> 
> I'm just listing the packages; I'm refering to "MinGW Runtime."

I think the "MinGW Runtime" means the 'mingwex' thing in cvs,
which is really just a set of extensions to the C runtime library.
"Environment" sounded like a shell to me.

>>>MSYS provides the minimal environment necessary to run UNIX-style
>>>makefiles and configure scripts on Windows. Among the useful tools
>>>it provides are awk, cat, cp, grep, ls, mkdir, mv, rm and sed. MSYS
>>>was designed to work with GCC, and it does so beautifully; it has
>>>trouble with other Windows toolsets, however, especially if they
>>>take command-line options beginning with a slash (/).
>>
>>Certain msw conventions, like slash as an option prefix, or paths
>>with embedded spaces, conflict with *nix conventions. Those conflicts
>>are a problem with Cygwin as well as MSYS, but the last sentence above
>>almost seems to imply that they're a worse problem for MSYS, which I
>>don't think would be correct.
> 
> I've had two problems using MSYS with non-GNU toolsets: options using slashes
> are interpretted as file pathanames and modified to point into the MSYS root
> directory, and command-line tools called "link" are confused with the command
> for creating filesystem links, even if the tool-name is fully qualified.
> 
> Right now, I can't replicate the second problem, but I don't know how to solve
> the first. I posted a message here a few weeks ago and got no response.

Was it this?
  06 Jun 2005 01:21:29 -0600
  Spurious pathname tranformations applied to /xxx switches

| For instance, /EHsc becomes C:/Tools/msys/1.0/EHsc

That started a thread of several messages, but maybe the only
one that addressed your question directly was Earnie's of
6 Jun 2005 10:53:08 +0000 , which said:

| Does ``make --win32'' help?

> If
> someone can show me how to fix the first problem, I can remove the line about
> MSYS having trouble with certain toolsets.

As far as I know, that problem is specific to MSYS, so I'd
have to agree with you.

>>Backslash-delimited paths are typical in the msw world, although as
>>far as I know most msw programs except CMD.EXE and COMMAND.COM happily
>>accept posix paths as command-line arguments. I have the impression
>>that MSYS strives harder than Cygwin to accept paths like
>>'C:\foo\bar'.
> 
> As I said, it's not a problem with handling DOS-style paths, but with
> command-line options being treated as POSIX-style paths.

OK, yes, that's the other side of the coin--I had missed that, sorry.
I think this testcase illustrates what you're discussing:

  MSYS:

$ xcopy /?
Invalid parameter - /msys/1.0
$ xcopy '/?'
Invalid parameter - /msys/1.0
$ xcopy "/?"
Invalid parameter - /msys/1.0

  CMD.EXE:

C:\Documents and Settings\chicares>xcopy /?
[does what is says on the tin]
C:\Documents and Settings\chicares>xcopy '/?'
Invalid parameter - /?'
C:\Documents and Settings\chicares>xcopy "/?"
Invalid number of parameters

  an msw port of zsh:
C:/tmp[0]$xcopy /?
zsh: no matches found: /?
C:/tmp[1]$xcopy '/?'
[does what is says on the tin]
C:/tmp[0]$xcopy "/?"
[does what is says on the tin]