Re: bug: cygwin 2.0 doesn't work at all

[Warren Young <wyml@etr-usa.com>]

On Apr 28, 2015, at 3:57 AM, Leonid Mironov <lvm@royal.net> wrote:
> 
> Upgrading cygwin package to 2.0 broke [almost] all programs using cygwin1.dll

WJJFM on Windows 10, both word sizes.

>    c:\cygwin\bin
>    C:\Windows\system32
>    C:\Windows
>    C:\Windows\System32\Wbem
>    C:\Windows\System32\WindowsPowerShell\v1.0\
>    C:\Oracle\product\11.2.0\client_1\bin
>    c:\util
>    c:\batch
>    c:\util\tccle
>    c:\util\sysinternals
>    .
>    C:\util\winMerge
>    c:\cygwin\bin
>    c:\util
>    c:\util\sysinternals
>    C:\ProgramData\Oracle\Java\javapath
>    c:\cygwin\bin
>    C:\Windows\system32
>    C:\Windows
>    C:\Windows\System32\Wbem
>    C:\Windows\System32\WindowsPowerShell\v1.0\
>    C:\Oracle\product\11.2.0\client_1\bin
>    c:\util
>    c:\batch
>    c:\util\tccle
>    c:\util\sysinternals
>    .
>    C:\util\winMerge

I doubt this is the real problem, but there are some problems here:

1. Something is duplicating whole sections of the PATH.  The Cygwin bin directory appears three times!

2. You should never put . in the PATH.  Native Windows shells already behave as if . is in the PATH without needing it to be explicitly present, and Unix systems never ship with . in the PATH, for security reasons.  Get into the habit of saying “./myprogram” when running something in the local directory instead.

3. If you ran cygcheck from a cmd.exe shell, that means you’ve put the Cygwin bin directory into the native PATH.  While this can be the right thing in some circumstances, there are enough problems with it that it’s worth reconsidering. 

(One case in point is warned about by cygcheck: Cygwin programs shadowing native programs like find.exe.)
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple