This is the mail archive of the
mailing list for the Cygwin project.
RE: Conflict CYGWIN-autoconf(2.13)
- To: Heribert Dahms <heribert_dahms at icon-gmbh dot de>, 'Erik Hensema' <erik dot hensema at group2000 dot nl>, cygwin at sourceware dot cygnus dot com
- Subject: RE: Conflict CYGWIN-autoconf(2.13)
- From: Earnie Boyd <earnie_boyd at yahoo dot com>
- Date: Sat, 30 Oct 1999 20:18:30 -0700 (PDT)
- Reply-To: earnie_boyd at yahoo dot com
--- Heribert Dahms <email@example.com> wrote:
> Hi Kai,
> how exactly does it break Cygwin?
> If autoconf is run from within Cygwin's bash, cygwin.dll is already
> loaded and CYGWIN is IIRC honored only at initial startup.
> The you say autoconf sets CYGWIN in either case, so the
> previous value doesn't matter for the to-be-configured stuff, and
> the new value does not influence the already loaded cygwin.dll.
Uhm... Modifying the CYGWIN variable after cygwin1.dll has loaded can affect
the children processes after the change. It is process driven. There are some
items that affect the parent shell process to the point that the switch should
never be changed for the children. In particular, the tty switch causes the
stdin, stdout and stderr fds to be processed in binary mode. The default for
value for this switch is notty which causes the std fds to be processed in text
mode. Another interesting switch is the [no]binmode switch. It's default is
binmode and if I want nobinmode and autoconf changes it I'm not going to be
very happy. Yea, I know that the child process settings won't affect the
parents but I still wouldn't be very happy.
Earnie Boyd <mailto:firstname.lastname@example.org>
Newbies, please visit
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
Want to unsubscribe from this list?
Send a message to email@example.com