[EMAIL PROTECTED] wrote:
> Some strictly positive amount of interoperability exists.
> When I gcc c:/cygwin/home/15-6-1/tmp/m/sample.c, it
> produced a.exe (gcc 'c:\cygwin\home\15-6-1\tmp\m\sample.c', too).
>
> sample.c contained
> #include<stdio.h>
> int
> main(void)
> {FILE*f=fopen("c:\\sample.txt","w");
> if(f){fprintf(f,"no camel\n");fclose (f);}
> else printf("fail\n");return 0;
> }
> , and when I ./a.exe, the named c:\sample.txt appeared
> (I tried also "c:/sample.txt" with the same result).
I never said that fopen("c:/foo") wouldn't work, but it's because the
Cygwin APIs simply pass-thru arguments to the underlying Win32 APIs that
don't look like POSIX paths. When you use Win32 pathnames in this
context you bypass all Cygwin mount table code for instance, which means
that if you are relying on the mount table setting of textmode or
binmode to change the default file mode, it won't work. And this says
nothing of application code that manipulates paths, such as the 'make'
example. There are other examples, such as tar:
$ tar cf c:/tmp/foo.tar foo
rcmd: getaddrinfo: hostname nor servname provided, or not known
tar: c\:/tmp/foo.tar: Cannot open: Input/Output error
tar: Error is not recoverable: exiting now
In the 'tar' command line syntax, ':' indicates a remote host.
> There is no guarantee that anything will work;^)
There is such a thing as supported ("if it breaks we will do our best to
fix it") and unsupported ("it may happen to work, but we won't go out of
our way to unbreak it if it ever ceases to work") and that is what is
meant by guarantee here. And that is why there has been no particular
rush to publish an updated 'make' Cygwin binary package that supports
win32 paths despite many long and repeated mailing list threads about
users complaining that make can't grok drive letters in rules.
Brian
