text / binary mounts (sorry)

David Bolen db3l@fitlinxx.com
Fri Jun 2 19:45:00 GMT 2000


Chris Faylor [cgf@cygnus.com] writes:

> It only affects stdin/stdout behavior when the program is run from the
> Windows command shell.

Well, it also happens for me when a process is started up from an NT service
(that is not a Cygwin service) which has no bearing on a command shell, or
actually any NT application (even if while the application was started from
a shell, the process it is creating will have no interaction with that
shell)  (That might be synonymous with what you mean by "command shell" I'm
not sure).

> fork() is a cygwin function which produces an additional copy of a running
> program.  That means that the child has a a cygwin parent and so stdin
should
> be in the same state in the child as in the parent.

Oops, I think I mis-stated - I meant to say is started as a child process
(but my Unix-based brain optimized that phrase with "fork()").  I haven't
tested all cases, but the actual problems I was running into did involve a
parent process (not interactive) that was not Cygwin-based.

I do believe you are correct in the behavior under fork() which was actually
part of the confusing part when I tried to diagnose this originally (which
led to my first note to this list which led off onto a tangent on open
source :-)) - I had thought it was the internally forked child but it was
actually the original stdin/stdout .

-- David

/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com



More information about the Cygwin mailing list