Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Subject: RE: why must cygwin be first in path?
Date: Fri, 4 Feb 2000 08:06:49 -0700
Message-ID: <NDBBIAJFPMMEEGPCHFODCECMCBAA.sschram@aircell.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3899E32E.A644A40F@veritas.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
To: "Bob McGowan" <Robert DOT McGowan AT veritas DOT com>
From: "Steven Schram" <sschram AT aircell DOT com>
Cc: <cygwin AT sourceware DOT cygnus DOT com>

How fast is your test computer?  In my case, bash takes no perceptible time
to start -- no matter whether cygwin1.dll is currently loaded or has been
loaded recently.   On the other hand, make starts quickly but pauses before
processing the Makefile only if the PATH is arranged 'incorrectly' and only
if the pause hasn't occurred in the last 10 seconds.  It seems important to
note that the delay happens every 10 seconds even if make is executed
repeatedly.  Also, it need not be executed from an interactive shell.  I use
Visual SlickEdit and it executes make via a non-interactive cmd.exe shell.
The delay does occur in this case.

BTW, thanks for running the test.

Steve

-----Original Message-----
From: Bob McGowan [mailto:Robert DOT McGowan AT veritas DOT com]
Sent: Thursday, February 03, 2000 1:21 PM
To: earnie_boyd AT yahoo DOT com
Cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: why must cygwin be first in path?


Earnie Boyd wrote:
>
> --- Steven Schram <sschram AT aircell DOT com> wrote:
> > The only way I have found to get GNU Make to execute properly from the
NT
> > Command Shell is to put the cygwin directory first in the PATH variable.
>
> It has always been advised to put the Cygwin directory first in the PATH.
This
> hasn't changed in anyway.
>
> > Otherwise, 'make.exe' has that strange delay (about 3 seconds) I
mentioned a
> > while back.  Does this give anyone a clue as to why there is a delay at
all?
> >
>
> What network devices are on the PATH?
>
> Regards,
>
> =====
> Earnie Boyd <mailto:earnie_boyd AT yahoo DOT com>

Regarding the path, I think the primary reason for having Cygwin first
is so the Cygwin tools are found first in a path search.  I have the NT
Resource Kit installed and it has versions of ls.exe, rm.exe, vi.exe,
etc., which I don't want (usually) to run.  They don't understand the
Cygwin environment, so if they get picked up instead of the Cygwin
version while running something like a makefile or a script, strange
things can happen.

As to the delay of startup for 'make' from a command prompt, I just did
the following experiment.  I am a test engineer working with NT2K, so I
had a "clean" (OS just installed) system available and installed the
Cygwin CD 1.0 files.  After the suggested reboot, I opened a command
prompt window and started bash there, timing it with my wristwatch.  It
took just over 4 seconds to print a prompt.  I exited the bash shell and
immediately restarted it.  The delay was less than half a second this
time.  Only local drives are in the path.  However, the path was the
default after install, which has the Cygwin paths _after_ the NT paths.

This looks to me like it is partly a disk read/load issue.  Code for
both bash and the DLL need to be read into RAM from disk the first time,
the second time most if not all is in RAM and so the read delay is
eliminated.  This is a guess on my part, I am not an NT internals
expert.  Some of the delay may be due to other events that I know
nothing about.

Since I seldom (never, actually) use the command prompt, I don't see
this type of delay, probably because the DLL code is in use due to the
bash shell started from the 'Start' menu shortcut and so is immediately
available to use when other tools (like make) run.

--
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan AT veritas DOT com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com