why must cygwin be first in path?
Fri Feb 4 07:07:00 GMT 2000
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.
From: Bob McGowan [ mailto:Robert.McGowan@veritas.com ]
Sent: Thursday, February 03, 2000 1:21 PM
Subject: Re: why must cygwin be first in path?
Earnie Boyd wrote:
> --- Steven Schram <email@example.com> 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
> > while back. Does this give anyone a clue as to why there is a delay at
> What network devices are on the PATH?
> Earnie Boyd < mailto:firstname.lastname@example.org >
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
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.
Staff Software Quality Engineer
Want to unsubscribe from this list?
Send a message to email@example.com
More information about the Cygwin