Message-ID: <47DDA691.9060907@tlinx.org>
Date: Sun, 16 Mar 2008 16:00:33 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: compiling C w/cygwin vs. -mno-cygwin; inconsistent "C" behavior
References: <47DCE267 DOT 5060508 AT tlinx DOT org> <47DCF4D4 DOT 7C1061BB AT dessent DOT net>
In-Reply-To: <47DCF4D4.7C1061BB@dessent.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Brian Dessent wrote:
> Linda Walsh wrote:
> 
>> When I use the "no-cygwin" version, filenames with spaces in them get split into
>> separate arguments, but if I run the "cygwin" version, the file name isn't split
>> on space boundaries.
>>
>> I'm 'guessing', but shouldn't the breaking of apart of arguments behave
>> the same whether I compile with cygwin or -mno-cygwin?
> 
> No, what you're seeing is totally expected behavior.  In native windows
> if you want to support filenames with spaces, you have to include
> physical quote characters in the command line.
----
	Well that's just special.  But something doesn't add up.  How
could the cygwin wrapper know what character strings to bind together as a 
filename?  If I say "gvim file with space", in either the cygwin version
or the nocyg, it will try to edit 3 files.  When I am invoking
the redirector, I'm using 1 set of double quotes:
gvim "file with space"
in both versions w/cyg & w/o-cyg.  cmd.exe also requires quoting filenames with 
spaces the same as bash.

For some reason, the multiple args in the redirector are being merged -- I
I can get the quoting to work in the no-cyg case by using 2 sets of quotes:
gvim '"file with space"'

So cygwin pays attention, and my re-passing the args via "execv"
preserves the quoting of filenames, but the no-cyg version appears
to take the argv[1..#] arguments and merge them into 1 argument.
To do the same in the no-cyg version, I'd have to peel each arg
off, put quotes around it, then call execv with everything requoted.

So 'cygwin' appears to "requote" arguments that are passed 'in' whereas
the no-cyg version does not.  Explaining another way:

I have main(int argc,char * const argv[]);
I execute the program like this:
	gvim[+/-]cygwin.exe "Filename with space".
In both the +cyg and the -cyg case, I get an argc value of "2".
With both, I get some form of the program name in argv[0], and then
I get the "Filename with space" (without the quotes) in argv[1].

Then I call execv(cmd, argv);

So you are saying that when I call execv in cygwin, it unpacks
my 'argv', and makes a new 'argv' with quotes around each string?
and that is what gets passed to create process?  Does it use
single or double quotes?

> That's because
> CreateProcess does not actually have an argv, there is no such thing as
> an argv in windows -- a process gets created with a monolithic command
> line.  If it wants that command line in the form of individual
> arguments, it has to parse it (or ask the system/CRT to parse it for
> it.) 

But the executed program, with or without cygwin, already has the
arguments parsed when main is invoked.
I.e. when either the cygwin or no-cyg program is invoked, they both
have the same view of the arguments in 'argv'.

It's execv that's falling down, not doing it's job.  My arguments
are already parsed and separated, but the no-cyg version of execv
is mushing them all back together, while cygwin invokes the
next program, apparently with quotes of some sort, around the
contents of each, separate, argv[] string.


That means that the only way to make arguments with spaces survive
> intact is by quoting.
----
	Right ...
> 
> And Cygwin does that quoting for you.  The native runtime MSVCRT does
> not, which is what is executing when you're using -mno-cygwin. 
----
	Isn't MSVCRT the startup code?
  If you
> don't like its behavior then take it up with Microsoft, it's out of our
> hands.  There is no guarantee of consistency whatsoever, because
> -mno-cygwin literally means "don't use any Cygwin, use the Microsoft
> runtime (MinGW)".

I don't think it is a MS problem exactly -- it appears to be a
broken implementation of execv.  When I call execv, the different
file arguments are already "collected" together, with 1 file name
per 'argv[]' array element.  Cygwin "honors" arguments that are
collected together in 1-string (pointer of which is passed in
1 argv element) and "somehow" calls the desired program maintaining
the grouping of the contents of each "argv" element.  You say that
the standard way to do that is to quote the contents of each full argv
string separately, 1 quoted string/argv element.

I'd say that the no-cyg version of execv isn't maintaining the separation
of the arguments.  It's just mushing them all together and not passing
the correct argument separation to "createprocess".
Am I missing something?

> For what it's worth the MinGW project has a set of exec() wrappers that
> help to sanitize the situation a little.
---
	I think that's where the problem is.

	I've also run into another unexpected behavior difference.
The no-cyg version of _my_ gcc wrapper, is automatically detaching
from the terminal and going into the background (running under bash).
Is there some reason cygwin waits around until my wrapper is finished,
but the no-cyg version (same code) doesn't?....I suppose it is
easier when launching another program with createprocess -- to hmmm...
shouldn't the exec call "end" or terminate the execution of the wrapper?

	Since I'm not forking -- I'm exec'ing, the redirector should
cease to exist (exit), but under cygwin, it does not.  That seems more
of a bug in the cygwin implementation, no?

Thanks...
-linda

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/