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 12:02:47 -0800
Subject: RE: default PATH
Message-ID: <2A9FABB3664AF8459CBADA1CE4E402463D1BF1@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
In-Reply-To: <20060210190116.GL14219@calimero.vinschen.de>
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

On Friday, Feb 10, Corinna wrote:
" On Feb  8 18:59, Dave Korn wrote:
" > On 08 February 2006 13:06, Eric Blake wrote:
" > > Yes, this is correct behavior, but it often catches people by surprise.
" > > POSIX requires an empty string in your PATH to be treated as the current
" > > directory, and while people are less likely to start their Windows PATH
" > > with ; or to have ;; in the middle, a trailing ; is pretty common from
" > > applications that don't know any better on Windows.
" > 
" >   No, it's not quite correct behaviour - but the incorrectness isn't in the interpretation of $PATH, but in the way it is translated
" > from %PATH%.
" > 
" > Since POSIX semantics requires an empty path component to be treated as
" > $CWD, but Win32 semantics require an empty path component to be ignored,
"             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
" 
" How do you know that?  Can you give me a pointer describing that?  I
" searched MSDN and KB and found not a word about how multiple semicolons
" are treated by Win32 functions or cmd/command.  This is tricky to test
" since, for instance, CreateProcess searches the current directory anyway
" before using %PATH% (see MSDN).

I suspect that there is no definitive answer here, but one more datapoint:
	path ?
on Win2K3 and WinXP includes the text
	Type PATH ; to clear all search-path settings and direct cmd.exe
	to search only in the current directory.
Actually invoking PATH ; results in my PATH being null.  I conclude from this
that a) the bit about only searching the current directory is the implicit
search CreateProcess does and b) empty path components (the empty strings
before and after the lone semicolon) are _not_ to be considered the current
directory, since the PATH command felt happy to throw them and their separating
semicolon away.

" > the code that translates %PATH% to $PATH is not performing
" > the translation correctly.  It should strip out empty components from
" > the win32 path if it wants to get a semantically-equivalent path
" > setting.  Translating an empty win32 path component into an empty
" > posix path component is not translating like into like.
" 
" I'm wondering how other people think of that.  In theory we could
" change Cygwin to ignore ";;" sequences and not to add "." to $PATH,
" or we can just keep it as it is.

Given the experiment above, as well as my experience (see below) I'm inclined
to agree with Dave.

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

More explicitly, I believe that the implicit CreateProcess search of .
means, in practice (not by any formal rule) that Windows users don't
intend to put the current directory on their paths.  I believe the vast
majority of multiple and trailing semicolons are the sloppy install
programs, and perhaps occasional sloppy users.  In the dev environment
I maintain for many devs at work, my  startup scripts explicitly squeeze
out semicolons while fixing up %PATH% to remove this ambiguity (and also
simplify further processing).

So, I think it's not unreasonable to squeeze out multiple and leading and
trailing semicolons from the Windows path before doing the translation --
i.e. lose the empty components, don't turn them into dots.  This approach
(Corinna's second point of view above) is, I think, the truest translation
of %PATH% to $PATH.

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

I like this because it's truer to preserving the user's Windows overall path
semantics and is more deterministic than the typical current accidental case
-- a Windows user automatically gets . first because of CreateProcess, and
happens to get . somewhere in their $PATH under Cygwin if they're sloppy
with the semicolons, so doesn't notice the subtle difference in order.
Other users don't get . at all because they have a tidy %PATH%, and may or
may not notice under Cygwin.

On the other hand, I don't like this because it means that the evil that
is the implicit CreateProcess . search is now pushed into Cygwin.  Of
course, a user who cares can munge $PATH after the automatic conversion to
remove a leading . if they don't like it.  I munge $PATH a whole bunch
in .bashrc anyway to rearrange things so that Cygwin things are preferred
before Windows things in cases where they overlap. (e.g. in cmd.exe,
I want ActiveState perl to be early; in Cygwin bash, I want Cygwin perl to
be early).  If this sort of munging is common, then adding the bit to
deal with the new leading dot is maybe not a big deal.

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.

" Corinna

hope this helps, my $0.02, YMMV, &c.
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/