Date: Sat, 11 Feb 2006 15:41:53 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: default PATH
Message-ID: <20060211204153.GA14065@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20060210190116 DOT GL14219 AT calimero DOT vinschen DOT de> <2A9FABB3664AF8459CBADA1CE4E402463D1BF1 AT DF-MASTIFF-MSG DOT exchange DOT corp DOT microsoft DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2A9FABB3664AF8459CBADA1CE4E402463D1BF1@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
User-Agent: Mutt/1.5.11
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

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.

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

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

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.

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.

cgf

--
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/