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 15:24:23 -0800
Subject: RE: default PATH
Message-ID: <2A9FABB3664AF8459CBADA1CE4E402463D1BFA@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
In-Reply-To: <20060211204153.GA14065@trixie.casa.cgf.cx>
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

cgf wrote:
" On Sat, Feb 11, 2006 at 12:02:47PM -0800, Stephan Mueller wrote:
" >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.
" 
" We know that Windows searches the current working directory no matter
" what you do so 1) there doesn't seem to be any way of knowing how
" Windows would interpret a ;; and 2) there is no way of knowing if the
" path command shell convention has anything to do with lower level
" windows internals.
" 
" So, I don't think this really answers Corinna's question.  I believe that
" she was looking for documentation which stated that ;; was ignored, not
" reasoning which implies it.

In the absence of the former, I'd hope the latter would be better than nothing.
I'd also consider that the text from PATH ? counts as documentation, and
conclusions drawn from the results of doing exactly what it says to be worth
something.

" >" > 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.
" 
" This is absolutely *not* something that we would do.

I'm not surprised at the objection to prepending '.'; I'm not sure I like it
myself.

" We're not trying to mimic
" Windows behavior.  We're trying to determine if there are people out there who
" are expecting ;; to be properly translated by Cygwin.

For Cygwin to properly translate %PATH% requires knowing what the Windows
semantics of ;; are.  Those semantics determine whether a dot should appear within
the POSIX path, not the POSIX semantics of ::.  How is this not mimicing Windows?
Put another way, if we're not interested in mimicing Windows, then the translation
can do anything it wants (although I'd hesitate to call it a translation then).

If the objection is that we don't want to expand the scope to "fidelity of %PATH%
translation as a whole" from "semantics of ;;", that's fine -- I vote for
view point #2, and we can stop there.

As a user, I'll say that I put dot where I want it explicitly in my Cygwin PATH,
but I do in fact expect ;; to be translated properly, where to me, 'properly'
is by ignoring it, not turning it into '.', because that's my long-time belief,
based on much Windows environment experience, never challenged by contrary
evidence.  Also because in the Windows environment, treating ;; as ;.; offers
no benefit due to the implicit CreateProcess search, and in fact, would just
slow things down a little, redundantly searching the current directory, and
because it's clear that many trailing semicolons and ;; instances are caused
by sloppy installers adding their own directories, with clearly, no intention
to add . to the path.
 
" >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.
" 
" You don't have to worry about what CreateProcess does since it is
" supposed to always be called with an absolute path in Cygwin.

I think the CreateProcess behaviour under Windows (i.e. for non-Cygwin cases)
matters somewhat because it dictates part of the meaning of %PATH% in the
Windows environment.  The fact that the ubiquitous CreateProcess searches the
current directory first means that the expectation of Windows users will be
that the current directory will be searched first (or at least searched at
some point).

" We're
" just trying go figure out if removing the ;; translation will affect
" many people.  We're not looking to add things to the PATH.

I think it might.  There are likely many sloppy paths out there.  Nonetheless,
I think it's the right thing to do, and perhaps can be mitigated by the
slightly evil option 3, which is why I proposed it.

" There is a tradeoff here and I don't believe that we really know what
" the implications are.  You can speculate that thousands of people are
" affected by the ;; problem but we haven't had very many complaints about
" this and certainly people who are relying on ;; are not going to be
" sending email here since Cygwin is working as they expect.

Right now, sloppy Windows paths with ;; happen to result in dot getting added
to Cygwin paths, as you say.  This leads to Windows users with sloppy paths
having their expectations being met but in a roundabout, somewhat arbitrary
way.  I won't speculate on how many people have problems with ;;.  What I
do think is that translating ;; as empty and explicitly prepending . is
straightforward, faithful to Windows users expectations and more deterministic,
since it doesn't rely on the side effects of sloppy installers.

However, as is often the case where backwards compatibility is paramount,
doing nothing is a fine approach too.  Me, I have my dots in my paths where
I want them, and don't have a sloppy Windows path anywhere.

" Also, while skipping empty elements is a trivial operation, it is not
" without cost.  Every time that we have to guard the user against
" something like this, we add another nail to the "cygwin is slow" coffin.

Performance matters, but I hesitate to invoke it against correctness.  That is,
if there were consensus that skipping empty elements is the right answer, then
I'd hope that Cygwin would skip empty elements, even if it is an extra if and
a few more cycles in a common code path.  If there's no consensus on skipping
empty elements, and absolutely everything else is equal, then sure, go with
what's faster.

" cgf

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/