From: Stephan Mueller <Stephan DOT Mueller AT microsoft DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Sat, 11 Feb 2006 14:39:22 -0800
Subject: RE: default PATH
Message-ID: <2A9FABB3664AF8459CBADA1CE4E402463D1BF7@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
In-Reply-To: <021120062022.25491.43EE478C000D242F0000639322007456720A050E040D0C079D0A@comcast.net>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit

Eric writes:
" " > " There are two different points of view possible here:
" > " 
" > " - Changing an empty Win32 path component to a POSIX "." entry is in
" > "   Cygwin for a long time.  It's possible that people rely on this
" > "   behaviour, so changing it would break existing installations.
" > "   Removing "." from $PATH could easily be accomplished in a script.
" > " 
" > " - Changing an empty Win32 path component to a POSIX "." entry is an
" > "   inherently dangerous behaviour and should not be done automatically.
" > "   Adding "." to $PATH could easily be accomplished in a script.
" > 
" > 
" > " So, what's the way to go?  Any third possibility perhaps?
" > 
" > I'd also be inclined to consider explicitly prepending a dot in the
" > translation.  This means we're no longer just converting %PATH% to $PATH,
" > but rather, the CreateProcess behaviour involving %PATH% -- prepending a dot
" > is turning CreateProcess's implicit behaviour into something explicit.
" > 
" > 
" > The existing situation (point of view 1) is not horrible either, and has
" > the backwards compatibility thing going for it.  But I think I'd prefer
" > either 2 or 3.  3 has that bit of propagated evil from CreateProcess, but
" > is prehaps slightly more backwards compatible (breaking fewer installations)
" > than 2.
" 
" I strongly oppose option 3 - cygwin should never add '.' implicitly to the
" front of a POSIX path - if you are crazy enough to want dot there, put
" it there yourself explicitly.  But I like option 2, of squeezing ';;' into a
" single ':' (avoiding the implicit dot of $PATH '::'), and ignoring trailing ';'
" (again, avoiding the implicit dot of $PATH trailing ':').  If the user wants
" dot in the middle or at the end, automagically converted from
" the Windows %PATH%, then they can explicitly use ';.;' or trailing
" ';.' to make their intent clear.  And since Windows always implicitly
" prepends '.' to %PATH%, this might cut down on the traffic to this
" list of "how did . get on my $PATH?".  (Although it will probably
" increase the traffic of "why did ;; get turned into : instead of ::?")
" 
" --
" Eric Blake

I'm not surprised at the strong objection -- note I considered option 3 to be
propagating some evil myself.  Putting dot where you want it in the path _is_
the simplest, safest course of action, in Windows and in Cygwin, except that
in Windows, it does almost no good to try to manage this yourself because
of the unavoidable implicit CreateProcess search.

That said, option 3, as I proposed it, is _not_ to implicitly put a dot on front
of a POSIX path, it's to _explicitly_ add to the front of $PATH.  That is,
assuming a Windows
	set PATH=c:\windows;c:\windows\system32;c:\etc
that would be translated on entry to the Cygwin environment to
	PATH=.:/cygdrive/c/windows:/cygdrive/c/windows/system32:/cygdrive/c/etc
The dot is added as part of the translation from Windows-land.  After that
conversion, you can do what you want to it -- including removing it.  Since
removing it is considered desirable, why add it at all?  Because if the goal
is to translate the meaning of the Windows PATH variable, then that ought to
include translating the ugly parts.  Otherwise, it's not translation, it's
editing, which may or may not be better.

One can argue that the PATH variable doesn't include the dot in Windows and
so shouldn't in Cygwin, and that searching the current directory first in
Windows implicitly is evil, and I won't argue with any of that.  Corinna
was requesting other options, so here it is.

If a %PATH% to $PATH translation doesn't include a leading dot, it means that
if my current directory is c:\foo, and there's a bar.exe in that directory,
and c:\foo is not explicitly on the path, then from cmd.exe, typing bar will
execute bar.exe, and doing the same from bash with a translated path won't.

If we don't care about translating the path _that_ accurately, so be it.  I
can live with option 2, and option 1 has served well (except for occasional
confusion like that leading to this thread) too.

stephan();

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/