This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

compiling C w/cygwin vs. -mno-cygwin; inconsistent "C" behavior

Just noticed an oddity.  I wrote a redirector program to sit in
the win/sys32 dir and catch calls for 'gvim' and call the real prog
in the '/Prog/Vim' directory.

The program is:

char * const winpath="C:\\Prog\\Vim\\Gvim.exe";
int main (int argc,char * const argv[]) {

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?

Or does cygwin do some argument collection and parsing that isn't done in the
-mno-cygwin case?  I don't think any 'shell' parsing should be coming
into play in either case, and I would have expected "C" to behave the
same between cyg/nocyg.

At this point, I don't know which behavior is "correct".  The 'nocyg' version
works when called from the shell, but that's because the registry entries
that take filenames as arguments start w/a double-quote ("%1 or "%*), so
explorer calls gvim with the file args quoted.

Does cygwin do some extra quote processing of the arguments passed to
a 'main' in "C" that the no-cyg version should be doing, or is the no-cyg
version behaving "properly" (some how I doubt it).  If the no-cyg
version was behaving "properly", then that would mean people providing
alternate 'text-viewing' editors in "winzip" would have problems with
spaces in filenames, which are fairly common on Windoz.

I may be wrong (I often am), but it seems like the argument parsing
should work the same for the two version since there's no shell
involved, no?

Thanks for any sanity....

p.s. -- a somewhat irrelevant description of how/why I got to this point
follows.  I don't believe its necessary to understanding how 'C'
should be working and why cygwin's arg parsing 'works' (but works
differently than standard 'C' w/o the benefit of cygwin's parsing.

In case anyone was wondering why I'm only having these problems now, it
is a twisted story. I had been simply storing a 2nd copy (hard link,
actually) to the Win32-GVim in the system32 dir.
That had GVIM looking for it's runtime files in system32 as well.
To override that I used VIMRUNTIME, setting it as a Windows-env var,
to point to the runtime files (under /Prog).
However, when I'm running BASH in a console window, I usually edit, in the
same window I'm working in, using 'vi'. That cygwin 'vi' needs to use /usr/share/vim as a runtime. So VIMRUNTIME was unset in my bashrc
letting cyg-vim work normally.

This is all fine, except when I really want to use 'gvim', launching it from bash (using the vimdiff feature, for example, I need more than 80-cols wide). Invoking gvim from bash would pickup the sys32-copy and spew errors when vim couldn't find it's runtime in the system dir. This was rare enough that I just tolerated the problem and typed out the full path to gvim. I got tired of that and figured a 'redirector' should be all I would need. Thus my attempt at something only slightly more complicated, I thought, than 'Hello world.'. Unfortunately I'm finding that even the most trivial tasks seem to result in complexities totally out of proportion to the task(s) at hand. *sigh*...<and all I wanted to do was edit a file!> :-) And some people wonder why I don't take on larger tasks...

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]