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
Message-ID: <389B1424.8B218011@veritas.com>
Date: Fri, 04 Feb 2000 10:02:12 -0800
From: Bob McGowan <Robert DOT McGowan AT veritas DOT com>
Organization: VERITAS Software
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steven Schram <sschram AT aircell DOT com>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: why must cygwin be first in path?
References: <NDBBIAJFPMMEEGPCHFODCECMCBAA DOT sschram AT aircell DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Good question, I should have mentioned that info.  The machine is a dual
cpu system, 100 MHz each (slow), with 128 MB RAM.  SysInfo says I have
about 400 MB virtual memory.

So, I checked on a different machine, with 500 MHz cpu (single) but same
RAM and virtual size.  Starting bash from a command prompt takes less
than a second.

Steven Schram wrote:
> 
> 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

-- 
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