This is the mail archive of the
mailing list for the Cygwin project.
Re: why must cygwin be first in path?
- To: Steven Schram <sschram at aircell dot com>
- Subject: Re: why must cygwin be first in path?
- From: Bob McGowan <Robert dot McGowan at veritas dot com>
- Date: Fri, 04 Feb 2000 10:02:12 -0800
- CC: cygwin at sourceware dot cygnus dot com
- Organization: VERITAS Software
- References: <NDBBIAJFPMMEEGPCHFODCECMCBAA.email@example.com>
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.
> -----Original Message-----
> From: Bob McGowan [mailto:Robert.McGowan@veritas.com]
> Sent: Thursday, February 03, 2000 1:21 PM
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: Re: why must cygwin be first in path?
> Earnie Boyd wrote:
> > --- Steven Schram <firstname.lastname@example.org> wrote:
> > > The only way I have found to get GNU Make to execute properly from the
> > > 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.
> > 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
> > >
> > What network devices are on the PATH?
> > Regards,
> > =====
> > Earnie Boyd <mailto:email@example.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
Staff Software Quality Engineer
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org