> Thanks (and thanks to Corinna and Eric) for correcting my misconceptions.
You're welcome. I only wanted to follow up that (I don't know what
the heck happened to my head, but) when I was
referring to file descriptors, I was consistently and mistakenly using
"1" where "0" should have been used:
> I think that would create an unacceptable performance penalty for the child
> process.
The child process would not be affected at all! FILE* will be
unbuffered only in your
application, yet "cat" will read from a file descriptor "1" (and may
or may not apply any
buffering on top of it, such as
> What I think happens is that since you
> specify a full posix path to cmd, you get posix semantics and none of
> the Windows compatibilty crap kicks in.
that may be, if your very own suggestion to split the last arg in two worked
just fine with the full posix path, i.e. while this set of argumen
Thank you for your response. It may sound plausible but:
> you tell Cygwin that you want posix semantics
I can't remember seeing that posix semantics require a C library call
to modify arguments in the way the shell does; since when cygwin a
shell?
> split arg 2 into two args: "DIR" and "C:\\"
Hi,
Yesterday I asked about the double slash, but my question has got no
attention (despite some other activity
on the list). I deem the behavior as a bug. To make things more
evident (that it's a bug) one can replace "DIR"
with "ECHO" in the code I posted, and compare the outputs with and
withou
Hello,
Here's code that (if BUG is defined) does not work because it looks
like Cygwin doubles the backslash in args[2] when that gets passed to
CMD. If I add a trailing period (#undef BUG), the preceding backslash
does not get doubled, the command runs as it is supposed to.
Why there's an additi
6 matches
Mail list logo
