This is the mail archive of the
mailing list for the Cygwin project.
Re: why must cygwin be first in path?
- To: earnie_boyd at yahoo dot com
- Subject: Re: why must cygwin be first in path?
- From: Bob McGowan <Robert dot McGowan at veritas dot com>
- Date: Thu, 03 Feb 2000 12:21:02 -0800
- CC: cygwin at sourceware dot cygnus dot com
- Organization: VERITAS Software
- References: <email@example.com>
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 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?
> 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
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 firstname.lastname@example.org