Python 2.6 ?

[Yaakov (Cygwin/X)]

Jason,

What are your plans for upgrading the distro Python to 2.6?  I'm finally 
starting to see some programs require 2.6 now, so I think the time has 
finally come that to consider an upgrade.


Of course, any upgrade to Python affects a lot of packages, so I hope 
that we can coordinate this in order to have a smooth transition.



Yaakov

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

[ANNOUNCEMENT] Updated: mintty-0.5.7-1

[Andy Koppe]

Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
Mintty is based on code from PuTTY by Simon Tatham and team.

CHANGES
===
- Ctrl+slash now sends ^_ as in xterm.
- New --class command line option allows to change the name of
mintty's window class. That can make it easier to distinguish
different mintty windows in scripting tools like AutoHotKey.
- Dim mode is no longer limited to the 16 basic colours.
- Drop long path prefix ('\\?\') from Windows paths when opening files
or directories. Some programs couldn't deal with those properly.
- Bring the charset support into line with upcoming changes in Cygwin
1.7.2: use nl_langinfo(CODESET) instead of making assumptions about
locales without explicit charsets, and allow three-letter language
codes.
- The postinstall and preremove scripts should now work in non-admin setups.

QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'), and it's
also available in PDF format at
http://mintty.googlecode.com/files/mintty-0.5.7.pdf. Questions and
comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list at cyg...@cygwin.com. Please use the issue tracker at
http://code.google.com/p/mintty/issues/list to report bugs or suggest
enhancements.



To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

     *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

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

Re: Strange cygdrive problem

[Corinna Vinschen]

On Jan 25 22:56, Steve Woolet wrote:
> Avi Schwartz  cfftechnologies.com> writes:
> [...]
> I am seeing something very similar to Avi's problem, only mine is with AFS
> mounted drives.  I have three AFS mounted drives that show up under /cygdrive 
> as
> r/, y/, and z/ in addition to the normal c/.  
> [...]
>$ ls /cygdrive/r
>ls: cannot open directory /cygdrive/r: Not a directory
> 
> I updated my cygwin1.dll to the latest snapshot, but that did not help.
> [...]
> $ /usr/lib/csih/getVolInfo /cygdrive/r
> Device Type: 7
> Characteristics: 10
> Volume Name: 
> Serial Number  : 1234
> Max Filenamelength : 255
> Filesystemname : 
> Flags  : 4003
>   FILE_CASE_SENSITIVE_SEARCH  : TRUE
>   FILE_CASE_PRESERVED_NAMES   : TRUE
>   FILE_UNICODE_ON_DISK: FALSE
>   FILE_PERSISTENT_ACLS: FALSE
>   FILE_FILE_COMPRESSION   : FALSE
>   FILE_VOLUME_QUOTAS  : FALSE
>   FILE_SUPPORTS_SPARSE_FILES  : FALSE
>   FILE_SUPPORTS_REPARSE_POINTS: FALSE
>   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>   FILE_VOLUME_IS_COMPRESSED   : FALSE
>   FILE_SUPPORTS_OBJECT_IDS: FALSE
>   FILE_SUPPORTS_ENCRYPTION: FALSE
>   FILE_NAMED_STREAMS  : FALSE
>   FILE_READ_ONLY_VOLUME   : FALSE
>   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> 
> I can supply an strace file, if that is needed.

That would be a start.  Just an strace of an ls /cygdrive/r for now.

Looks like YA filesystem not handling an FileBasicInformation request
correctly.  Any problem if I send you pointers to Cygwin test DLLs via
PM?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: Strange cygdrive problem

[Corinna Vinschen]

On Jan 26 11:47, Corinna Vinschen wrote:
> On Jan 25 22:56, Steve Woolet wrote:
> > Avi Schwartz  cfftechnologies.com> writes:
> > [...]
> > I am seeing something very similar to Avi's problem, only mine is with AFS
> > mounted drives.  I have three AFS mounted drives that show up under 
> > /cygdrive as
> > r/, y/, and z/ in addition to the normal c/.  
> > [...]
> >$ ls /cygdrive/r
> >ls: cannot open directory /cygdrive/r: Not a directory
> > 
> > I updated my cygwin1.dll to the latest snapshot, but that did not help.
> > [...]
> > $ /usr/lib/csih/getVolInfo /cygdrive/r
> > Device Type: 7
> > Characteristics: 10
> > Volume Name: 
> > Serial Number  : 1234
> > Max Filenamelength : 255
> > Filesystemname : 
> > Flags  : 4003
> >   FILE_CASE_SENSITIVE_SEARCH  : TRUE
> >   FILE_CASE_PRESERVED_NAMES   : TRUE
> >   FILE_UNICODE_ON_DISK: FALSE
> >   FILE_PERSISTENT_ACLS: FALSE
> >   FILE_FILE_COMPRESSION   : FALSE
> >   FILE_VOLUME_QUOTAS  : FALSE
> >   FILE_SUPPORTS_SPARSE_FILES  : FALSE
> >   FILE_SUPPORTS_REPARSE_POINTS: FALSE
> >   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
> >   FILE_VOLUME_IS_COMPRESSED   : FALSE
> >   FILE_SUPPORTS_OBJECT_IDS: FALSE
> >   FILE_SUPPORTS_ENCRYPTION: FALSE
> >   FILE_NAMED_STREAMS  : FALSE
> >   FILE_READ_ONLY_VOLUME   : FALSE
> >   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
> >   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> > 
> > I can supply an strace file, if that is needed.
> 
> That would be a start.  Just an strace of an ls /cygdrive/r for now.
> 
> Looks like YA filesystem not handling an FileBasicInformation request
> correctly.  Any problem if I send you pointers to Cygwin test DLLs via
> PM?

Oh, btw., is that using the OpenAFS client?  Does anybody know if a
publically available AFS server for testing purposes exists somewhere?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

RE: Strange cygdrive problem

[Bengt-Arne Fjellner]

On Jan 26 11:47, Corinna Vinschen wrote:
> On Jan 25 22:56, Steve Woolet wrote:
> > Avi Schwartz  cfftechnologies.com> writes:
> > [...]
> > I am seeing something very similar to Avi's problem, only mine is with AFS
> > mounted drives.  I have three AFS mounted drives that show up under 
> > /cygdrive as
> > r/, y/, and z/ in addition to the normal c/.
> > [...]
> >$ ls /cygdrive/r
> >ls: cannot open directory /cygdrive/r: Not a directory
> >
> > I updated my cygwin1.dll to the latest snapshot, but that did not help.
> > [...]
> > $ /usr/lib/csih/getVolInfo /cygdrive/r
> > Device Type: 7
> > Characteristics: 10
> > Volume Name: 
> > Serial Number  : 1234
> > Max Filenamelength : 255
> > Filesystemname : 
> > Flags  : 4003
> >   FILE_CASE_SENSITIVE_SEARCH  : TRUE
> >   FILE_CASE_PRESERVED_NAMES   : TRUE
> >   FILE_UNICODE_ON_DISK: FALSE
> >   FILE_PERSISTENT_ACLS: FALSE
> >   FILE_FILE_COMPRESSION   : FALSE
> >   FILE_VOLUME_QUOTAS  : FALSE
> >   FILE_SUPPORTS_SPARSE_FILES  : FALSE
> >   FILE_SUPPORTS_REPARSE_POINTS: FALSE
> >   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
> >   FILE_VOLUME_IS_COMPRESSED   : FALSE
> >   FILE_SUPPORTS_OBJECT_IDS: FALSE
> >   FILE_SUPPORTS_ENCRYPTION: FALSE
> >   FILE_NAMED_STREAMS  : FALSE
> >   FILE_READ_ONLY_VOLUME   : FALSE
> >   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
> >   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> >
> > I can supply an strace file, if that is needed.
>
> That would be a start.  Just an strace of an ls /cygdrive/r for now.
>
> Looks like YA filesystem not handling an FileBasicInformation request
> correctly.  Any problem if I send you pointers to Cygwin test DLLs via
> PM?

Oh, btw., is that using the OpenAFS client?  Does anybody know if a
publically available AFS server for testing purposes exists somewhere?


Corinna

/afs/openafs.org is at least readable for anyone

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

[no subject]

[Thomas Berger]

Hi Cygwinners,

On "XP Mode" on Windows 7 x64 I encounter the identical problem as described
in < http://cygwin.com/ml/cygwin/2007-04/msg00630.html >.

For a host drive mapped as G: <-> \\TSCLIENT\g "ls" yields

bash-3.2$ ls /cygdrive/g
ls: reading directory /cygdrive/g: Permission denied

The same share mapped as Y: <-> \\\g works as desired (because of
a huge M$-induced performance penalty this kind of mount is unfortunately not an
option for me)

Specific Info:

bash-3.2$ /usr/lib/csih/getVolInfo /cygdrive/g
Device Type: 7
Characteristics: 10
Volume Name: <>
Serial Number  : 1516020298
Max Filenamelength : 255
Filesystemname : 
Flags  : 3e700ff
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: TRUE
  FILE_PERSISTENT_ACLS: TRUE
  FILE_FILE_COMPRESSION   : TRUE
  FILE_VOLUME_QUOTAS  : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: TRUE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: TRUE
  FILE_SUPPORTS_ENCRYPTION: TRUE
  FILE_NAMED_STREAMS  : TRUE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : TRUE

bash-3.2$ /usr/lib/csih/getVolInfo /cygdrive/y
Device Type: 7
Characteristics: 10
Volume Name: <>
Serial Number  : 1516020298
Max Filenamelength : 255
Filesystemname : 
Flags  : c700ff
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: TRUE
  FILE_PERSISTENT_ACLS: TRUE
  FILE_FILE_COMPRESSION   : TRUE
  FILE_VOLUME_QUOTAS  : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: TRUE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: TRUE
  FILE_SUPPORTS_ENCRYPTION: TRUE
  FILE_NAMED_STREAMS  : TRUE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

What to do?

viele Gruesse
Thomas Berger

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

Re: Strange cygdrive problem

[Corinna Vinschen]

On Jan 26 12:08, Bengt-Arne Fjellner wrote:
> On Jan 26 11:47, Corinna Vinschen wrote:
> Oh, btw., is that using the OpenAFS client?  Does anybody know if a
> publically available AFS server for testing purposes exists somewhere?
> 
> 
> Corinna
> 
> /afs/openafs.org is at least readable for anyone

Thanks, but apparently I'm too dumb to set this up.  I have no idea
how to configure the OpenAFS client to access this.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: Compiling strings with nonascii chars.

[Eric Blake]

According to Andy Koppe on 1/25/2010 10:53 PM:
>> let _ = print_DEBUG "Fin du chargement dynamique éventuel"
>>
>>
>> I have done some testing and it looks like I get an error on any string 
>> literal which contains non-ascii chars.

> This might be a case of the source being
> encoded in ISO-8859-1 while the compiler tries to interpret it as
> UTF-8.

Another thing to consider - use escape sequences (octal or hex) rather
than literal characters, to make your source file ASCII-only; this has the
benefit of making the encoding of the character literal independent of the
encoding of the compiler, so your code is portable to other machines where
the compiler is run with a different locale.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: pre-compiled octave-3.2.4 for cygwin.

[George Barrick]

   2009.01.26.13:28:02 UT

Hey cygwin-octave folks (and Marco),

  I ran the command "$ cygcheck cygwin-3.2.4.exe"
as Marco Atzeri suggested, and got the output:

 cyg_octave20100125.txt >
Found: D:\cygwin\bin\octave-3.2.4.exe
Found: D:\cygwin\bin\octave-3.2.4.exe
Found: D:\cygwin\bin\octave-3.2.4.exe
Found: D:\cygwin\bin\octave-3.2.4.exe
Found: D:\cygwin\bin\octave-3.2.4.exe
D:\cygwin\bin\octave-3.2.4.exe
  D:\cygwin\bin\cygoctinterp.dll
D:\cygwin\bin\cygcruft.dll
  D:\cygwin\lib\lapack\cygblas-0.dll
D:\cygwin\bin\cygwin1.dll
  C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\RPCRT4.dll
  C:\WINDOWS\system32\Secur32.dll
D:\cygwin\bin\cyggcc_s-1.dll
  D:\cygwin\lib\lapack\cyglapack-0.dll
D:\cygwin\bin\cyggfortran-3.dll
  D:\cygwin\bin\cygstdc++-6.dll
D:\cygwin\bin\cygoctave.dll
  D:\cygwin\bin\cygfftw3-3.dll
  D:\cygwin\bin\cygfftw3f-3.dll
  D:\cygwin\bin\cygqrupdate-0.dll
  D:\cygwin\bin\cygreadline7.dll
D:\cygwin\bin\cygncurses-9.dll
C:\WINDOWS\system32\USER32.dll
  C:\WINDOWS\system32\GDI32.dll
D:\cygwin\bin\cygGL-1.dll
  D:\cygwin\bin\cygX11-6.dll
D:\cygwin\bin\cygxcb-1.dll
  D:\cygwin\bin\cygXau-6.dll
  D:\cygwin\bin\cygXdmcp-6.dll
  D:\cygwin\bin\cygXext-6.dll
D:\cygwin\bin\cyghdf5-0.dll
  D:\cygwin\bin\cygz.dll
cygcheck: track_down: could not find cygGLU-1.dll


As Marco indicated, the fix was to make certain
that the package libGLU1 is installed under cygwin.
The conclusion is that the libGLU1 (at least under
the cygwin environment) is now one of the things
upon which octave-3.2.4 depends.

Thank you for your help, Marco.

George  gbarr...@walsh.edu



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

Re: pre-compiled octave-3.2.4 for cygwin.

[Marco Atzeri]

--- Mar 26/1/10, Krause, Joe  ha scritto:

> It appears that
> the new cygwin distribution forgets to get the cygwin setup
> program to install the package containing
> cygGLU-1.dll. 
>    
> - Joe Krause 
> 

I know, it have also other "not visible" problems.
I am just uploading a new version with the 
right dependency

Regards
Marco






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

Re: Python 2.6 ?

[Jason Tishler]

Yaakov,

On Tue, Jan 26, 2010 at 02:55:23AM -0600, Yaakov (Cygwin/X) wrote:
> What are your plans for upgrading the distro Python to 2.6?

I was waiting for Cygwin 1.7 to be released.  I guess I can't use that
excuse anymore... :,)

> I'm finally starting to see some programs require 2.6 now, so I think
> the time has finally come that to consider an upgrade.

Agreed, especially since the Python web site indicates the following:

The current production versions are Python 2.6.4 and Python 3.1.1.

> Of course, any upgrade to Python affects a lot of packages,

Wow, I didn't realize there were so many Cygwin packages dependent on
Python:

$ wget -q -O - http://mirror.nyi.net/cygwin/setup.ini | \
grep '^requires:.* python' setup.ini | wc -l
54

> so I hope that we can coordinate this in order to have a smooth
> transition.

What do you propose?  Should I release a Python 2.6 as experimental, use
alternatives, or another approach?

BTW, is the threading workaround mentioned in the following post still
necessary?

http://cygwin.com/ml/cygwin/2009-07/msg00831.html

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

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

Re: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Christopher Faylor]

On Mon, Jan 25, 2010 at 10:28:56PM -0500, Charles Wilson wrote:
>Meh.  Unlike linux, there is a significant portion of the cygwin user
>base that treats cygwin simply as a "build environment" -- but use a
>compiler for native win32 $hosts.
>
>I don't much like it, but that's reality.  (...why did Cygnus fund the
>early development, in the first place?  To have a windows-hosted build
>environment for xxx-target compilers: in this case, xxx = native-win32)

Cygnus funded the work to provide windows *hosted* cross compilers for
other architectures.  Targetting *native* targeted win32 did not come
until a couple into the life of the project.

cgf

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

FW: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Buchbinder, Barry (NIH/NIAID) [E]]

Christopher Faylor sent the following at Tuesday, January 26, 2010 9:38 AM
>On Mon, Jan 25, 2010 at 10:28:56PM -0500, Charles Wilson wrote:
>>I don't much like it, but that's reality.  (...why did Cygnus fund the
>>early development, in the first place?  To have a windows-hosted build
>>environment for xxx-target compilers: in this case, xxx = native-win32)
>
>Cygnus funded the work to provide windows *hosted* cross compilers for
>other architectures. Targetting *native* targeted win32 did not come
>until a couple into the life of the project.

references:
  
  See '4. "Harnessing the Power of the Internet"' on


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

Re: FW: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Christopher Faylor]

On Tue, Jan 26, 2010 at 10:14:44AM -0500, Buchbinder, Barry (NIH/NIAID) [E] 
wrote:
>Christopher Faylor sent the following at Tuesday, January 26, 2010 9:38 AM
>>On Mon, Jan 25, 2010 at 10:28:56PM -0500, Charles Wilson wrote:
>>>I don't much like it, but that's reality.  (...why did Cygnus fund the
>>>early development, in the first place?  To have a windows-hosted build
>>>environment for xxx-target compilers: in this case, xxx = native-win32)
>>
>>Cygnus funded the work to provide windows *hosted* cross compilers for
>>other architectures. Targetting *native* targeted win32 did not come
>>until a couple into the life of the project.
>
>references:
>  
>  See '4. "Harnessing the Power of the Internet"' on
>

Don't know if you're arguing with me or agreeing with me but I actually
helped in the creation of that paper.  I even presented parts of it in
Paris to a bunch of non-English-speaking people at one point.

Unfortunately, the referenced page mixes the term "native" to mean "runs
on windows" vs. "runs without cygwin".  The initial goal of the Cygwin
project was *always* to produce binaries which run in the Cygwin
environment.  The ability to produce objects which didn't rely on Cygwin
came after the project had been around for a couple of years.

cgf

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

RE: FW: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Buchbinder, Barry (NIH/NIAID) [E]]

Christopher Faylor sent the following at Tuesday, January 26, 2010 10:25 AM
>
>>Christopher Faylor sent the following at Tuesday, January 26, 2010 9:38
>>AM
>>>On Mon, Jan 25, 2010 at 10:28:56PM -0500, Charles Wilson wrote:
I don't much like it, but that's reality.  (...why did Cygnus fund
the early development, in the first place?  To have a windows-hosted
build environment for xxx-target compilers: in this case, xxx =
native-win32)
>>>
>>>Cygnus funded the work to provide windows *hosted* cross compilers for
>>>other architectures. Targetting *native* targeted win32 did not come
>>>until a couple into the life of the project.
>>
>>references:
>>  
>>  See '4. "Harnessing the Power of the Internet"' on
>>>l_papers/noer/noer_html/noer.html>
>
>On Tue, Jan 26, 2010 at 10:14:44AM -0500, Buchbinder, Barry (NIH/NIAID)
>[E] wrote:
>
>Don't know if you're arguing with me or agreeing with me but I actually
>helped in the creation of that paper. I even presented parts of it in
>Paris to a bunch of non-English-speaking people at one point.
>
>Unfortunately, the referenced page mixes the term "native" to mean
>"runs on windows" vs. "runs without cygwin". The initial goal of the
>Cygwin project was *always* to produce binaries which run in the Cygwin
>environment. The ability to produce objects which didn't rely on Cygwin
>came after the project had been around for a couple of years.

Chris,

I know better than to argue with you in general and on this subject in
particular.  (For those who don't know, Chris used to work for Cygnus
Solutions.)  I just thought that it might be useful to point those who
are interested to the official historical documentation.  If there is
something wrong in that documentation, I suggest that you take it up with
the web master, not me.  :-)

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


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

Re: FW: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Christopher Faylor]

On Tue, Jan 26, 2010 at 11:01:30AM -0500, Buchbinder, Barry (NIH/NIAID) [E] 
wrote:
>I know better than to argue with you in general and on this subject in
>particular.  (For those who don't know, Chris used to work for Cygnus
>Solutions.)  I just thought that it might be useful to point those who
>are interested to the official historical documentation.  If there is
>something wrong in that documentation, I suggest that you take it up with
>the web master, not me.  :-)

I was clarifying what was on the page someone wanted to use the words
there to "prove" that the project's goals were always to provide
"native" windows binaries.

cgf

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

Re: FW: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]

[Christopher Faylor]

On Tue, Jan 26, 2010 at 11:16:20AM -0500, Christopher Faylor wrote:
>On Tue, Jan 26, 2010 at 11:01:30AM -0500, Buchbinder, Barry (NIH/NIAID) [E] 
>wrote:
>>I know better than to argue with you in general and on this subject in
>>particular.  (For those who don't know, Chris used to work for Cygnus
>>Solutions.)  I just thought that it might be useful to point those who
>>are interested to the official historical documentation.  If there is
>>something wrong in that documentation, I suggest that you take it up with
>>the web master, not me.  :-)
>
>I was clarifying what was on the page someone wanted to use the words
  ^
  in case
>there to "prove" that the project's goals were always to provide
>"native" windows binaries.

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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Kazuhiro Fujieda]

>>> On Sun, 24 Jan 2010 17:23:58 +0100
>>> Corinna Vinschen said:

> The Unix consensus is apparently EUC-JP and that's what Cygwin 1.7.2
> will use as default as well.  If you want UTF-8, just use "ja_JP.UTF-8".

To change the default codeset of ja_JP to eucJP is ridiculous.
Any users of Japanese version of Windows don't use eucJP as
typical euncoding scheme. It will cause unnecessary confusion.

There is no difference between SJIS and eucJP on Cygwin command
line for the sake of the implementation of i18n API. If there is
any difference, we should correct it. To change the default to
eucJP isn't adequate.

Regards,
-- 
Kazuhiro Fujieda 


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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Corinna Vinschen]

On Jan 27 01:36, Kazuhiro Fujieda wrote:
> >>> On Sun, 24 Jan 2010 17:23:58 +0100
> >>> Corinna Vinschen said:
> 
> > The Unix consensus is apparently EUC-JP and that's what Cygwin 1.7.2
> > will use as default as well.  If you want UTF-8, just use "ja_JP.UTF-8".
> 
> To change the default codeset of ja_JP to eucJP is ridiculous.
> Any users of Japanese version of Windows don't use eucJP as
> typical euncoding scheme. It will cause unnecessary confusion.

Well, you can always use "ja_JP.SJIS".  As for the default charset, now
that we get extended NLS support, there are packages out there which
have messages files for ja_JP encoded in eucJP.  These are not shown
correctly if SJIS is the default.  And eventually you should use
"ja_JP.UTF-8" anyway.

> There is no difference between SJIS and eucJP on Cygwin command
> line for the sake of the implementation of i18n API. If there is
> any difference, we should correct it. To change the default to
> eucJP isn't adequate.

I don't understand this one.  The difference is the character encoding
which is compatible with other POSIX systems in the "ja_JP" locale
when eucJP is the default.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Git-gui and ssh key authenication

[Richard Lee]

Hi cygwin,

I'm not sure if this goes in the cygwin-apps list of here.

I'm running Cygwin 1.7.1 on XP SP3 Pro.

I'm having problems getting git-gui to use my ssh key. I can run git-gui
fine. But when I try to clone from my repo it asks for my ssh
passphrase. I'm assuming that this is because it can't connect to
ssh-agent.

I can clone fine using git-clone.

Regards,

Richard 

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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Andy Koppe]

2010/1/26 Corinna Vinschen:
>> Any users of Japanese version of Windows don't use eucJP as
>> typical euncoding scheme. It will cause unnecessary confusion.
>
> Well, you can always use "ja_JP.SJIS".
>
> As for the default charset, now
> that we get extended NLS support, there are packages out there which
> have messages files for ja_JP encoded in eucJP.  These are not shown
> correctly if SJIS is the default.

Another example is X11, which has its own locale system independent
from Cygwin's. There, "ja_JP" implies eucJP already. This means that
with LANG=ja_JP, xterm uses eucJP, while filenames and programs
currently use the system's ANSI codepage, i.e. CP932 on Japanese
systems. Result: mojibake. It does work correctly with
LANG=ja_JP.SJIS.

Andy

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

Re: Git-gui and ssh key authenication

[Richard Lee]

Hi again,

I hope this replies to the right thread.

I forgot to say I'm using Mintty. When it asks me for my passphrase it
asks me from the Mintty console I ran the "git gui" command from. Two
things happen here, my passphrase is displayed as I type it and when I
quit the git-gui, only every other key typed appears.

I tried to use it the regular Cygwin shell and it works better. Instead
of the passphrase prompt coming in the shell it comes up in a Tk dialog
box. But this time it successfully accepts my passphrase and
authenticates. But it still won't use ssh-agent.

Richard 

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

SSH password change request

[Jonathan Mailloux]

Hi everyone.
 
I modified "openssh-5.1p1-10" to allow SSH to have it login with a password and 
do some action on a single line. This is the result of a chain of problems I 
had to customize and automate our web installations here.
 
Syntax is as follow: ssh password:usern...@server [params] [actions] [etc...]
 
I wanted to submit this to cygwin-packages but I am having all the troubles in 
the world connectiong via cvs + v1.7 has gone out.
 
My problem
 
I’m trying to do the cvs login but when I enter the password, I always have a 
connection refused.
 
My request
 
The modification I made is fairly simple to do (I assume since I never done C++ 
and managed to get it working). I would like to ask if anyone would be willing 
to reproduce this modification I made and send it to cygwin-packages.
 
Ask me for the files I modified if you need them.
 
Thank you everyone and feel free to comment / help / teach me anything. This is 
my first interaction with an opensource ^^.
 
Jonathan Mailloux
Web Programmer IT Group Canada
_
Reinvent how you stay in touch with the new Windows Live Messenger.
http://go.microsoft.com/?linkid=9706116

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

Re: SSH password change request

[Corinna Vinschen]

On Jan 26 13:56, Jonathan Mailloux wrote:
> 
> Hi everyone.
>  
> I modified "openssh-5.1p1-10" to allow SSH to have it login with a password 
> and do some action on a single line. This is the result of a chain of 
> problems I had to customize and automate our web installations here.
>  
> Syntax is as follow: ssh password:usern...@server [params] [actions] [etc...]
>  
> I wanted to submit this to cygwin-packages but I am having all the troubles 
> in the world connectiong via cvs + v1.7 has gone out.

There are a couple of problems:

- OpenSSH is at 5.3p1, not at 5.1p1, so the patches probably won't apply
  cleanly to the latest from CVS.

- There is no cygwin-packages repository, there's only a cygwin-apps
  repository.

- OpenSSH is not maintained in cygwin-apps, but entirely upstream by the
  OpenBSD community.  See http://www.openssh.com/portable.html.

- The Cygwin version of OpenSSH is also maintained in the upstream
  source tree.  For CVS access to that tree, see the aforementioned web
  page at http://www.openssh.com/portable.html.  There's no
  Cygwin-specific patch which hasn't been accepted in the upstream
  repository and, as the Cygwin OpenSSH maintainer, I'm not willing to
  apply Cygwin-specific patches which won't go upstream.

- I'm very certain that the patch won't be accepted upstream, since
  there's nothing you can say which will the upstream maintainers
  convince to allow to specify a cleartext password on the command line.

- Last but not least, with Cygwin 1.7 there are very likely other
  solutions to your problems, see the Cygwin User's Guide at
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
  and especially at
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd2 and
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Readline problem on stand alone application

[Paul Budnik]

In the latest port of the ordinal calculator (www.mtnmath.com/ord) 
readline does not work. Backspace does not delete characters and the 
arrow keys do not move the cursor. The problem is reproducible with 
bash. Copy bash.exe and the dlls it uses to another directory and 
execute bash in that directory from the Microsoft command window. Doing 
so results in the same behavior in bash as I observe in my application.


If I execute the ordinal calculator either from a bash window or copy it 
to the CYGWIN bin directory it works properly but when I package it as a 
standalone application it fails. I even tried copying the entire CYGWIN 
bin directory to another location and executing from there. The problem 
still exists. I have updated CYGWIN in the last week. I did not have 
this problem on the first release of the ordinal calculator made last fall.


Paul Budnik
www.mtnmath.com



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

Re: Readline problem on stand alone application

[Christopher Faylor]

On Tue, Jan 26, 2010 at 11:28:00AM -0800, Paul Budnik wrote:
>In the latest port of the ordinal calculator (www.mtnmath.com/ord) 
>readline does not work. Backspace does not delete characters and the 
>arrow keys do not move the cursor. The problem is reproducible with 
>bash. Copy bash.exe and the dlls it uses to another directory and 
>execute bash in that directory from the Microsoft command window. Doing 
>so results in the same behavior in bash as I observe in my application.
>
>If I execute the ordinal calculator either from a bash window or copy it 
>to the CYGWIN bin directory it works properly but when I package it as a 
>standalone application it fails. I even tried copying the entire CYGWIN 
>bin directory to another location and executing from there. The problem 
>still exists. I have updated CYGWIN in the last week. I did not have 
>this problem on the first release of the ordinal calculator made last fall.

This isn't too surprising.  Cygwin 1.7.* determines its root directory
from the location of cygwin1.dll.  If you move cygwin1.dll to directory
c:\foo\bin it will look for other required files in, e.g.,
c:\foo\usr\share and won't be able to find them.  ncurses/terminfo need
files in /usr/share so they won't work correctly.

If you are packaging the Cygwin DLL with with other stuff you will need
to investigate the Cygwin mount table and possibly provide an /etc/fstab
file or copy more files into the other directory.

Btw, looking at the above web site, it seems like you may not be complying with
the GPL since you don't seem to be providing the sources for the binaries
you are distributing.  Pointing to the Cygwin web site is not enough.  You
have to provide source code for every binary that you provide.

cgf

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

Re: Python 2.6 ?

[Yaakov (Cygwin/X)]

On 26/01/2010 07:56, Jason Tishler wrote:

Agreed, especially since the Python web site indicates the following:

 The current production versions are Python 2.6.4 and Python 3.1.1.


Which raises another point: 3.x are meant to be installed in parallel 
with 2.x (/usr/bin/python3 instead of /usr/bin/python, etc.).  So a 
separate python3 package might also be in order.



Wow, I didn't realize there were so many Cygwin packages dependent on
Python:

 $ wget -q -O - http://mirror.nyi.net/cygwin/setup.ini | \
 grep '^requires:.* python' setup.ini | wc -l
 54


You think that's a lot?  Ports has another two to three *hundred* on top 
of that.  That's why I want this to be coordinated.



What do you propose?  Should I release a Python 2.6 as experimental, use
alternatives, or another approach?


That depends, primarily, if we intend on support more than one 2.x 
version at a time.  Until now, we have not.  (Of course, this does not 
preclude a python3 package, as stated above.)


Either way, I don't think we want to use alternatives, as that means 
that anybody can choose which version is their /usr/bin/python, etc. 
There must only be one default version of Python across the entire 
distro at any given time, otherwise things break.


So if we keep with only one 2.x version at a time, then 2.6.4 as 
experimental is probably the best bet, with a clear schedule to 
maintainers of when 2.6 will go stable so the transition has a chance of 
being smooth.  If, OTOH, we start supporting 2.5, 2.6, and (soon) 2.7 
simultaneously, then the packaging scheme for Python would need to 
significantly change.


While you're at it, could you please include my ctypes patches:

http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python2.6/2.5.2-ctypes-util-find_library.patch
http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python3/3.0rc3-ctypes-util-find_library.patch

This is critical for typical ctypes usage, where only a library name is 
given (e.g. PyOpenGL).  It means that the -devel package is required, 
but the same is true of the techniques used on Linux.



BTW, is the threading workaround mentioned in the following post still
necessary?

 http://cygwin.com/ml/cygwin/2009-07/msg00831.html


Last time I checked, yes for both 2.6 and 3.1.


Yaakov

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

Re: Problems starting sshd as a service on cygwin 1.7.1

[Myron Flickner]

Problem remains - If I repeat the cgyrunsrv -S sshd command eventually it 
works. 

Disabling Symantec Client Firewall didn't fix this.   

I've attached the cygcheck.out file.Is there any other tracing I can do ? 

 imaging away / flick


  

cygcheck.out
Description: Binary data
--
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

Re: Problems starting sshd as a service on cygwin 1.7.1

[Gregg Levine]

On Tue, Jan 26, 2010 at 6:40 PM, Myron Flickner  wrote:
> Problem remains - If I repeat the cgyrunsrv -S sshd command eventually it 
> works.
>
> Disabling Symantec Client Firewall didn't fix this.
>
> I've attached the cygcheck.out file.    Is there any other tracing I can do ?
>
>  imaging away / flick
>
>
>
Hello!
While the experts are sorting out your file, I have one comment and
one or two questions.

First the comment, check the spelling on that one, it isn't "cgyrunsrv
-S sshd", it happens to be "cygrunsrv -S sshd".

And now the questions, How did you originally install the service for
ssh? And what were those steps?

I have followed the majority of the ones listed in the rather well
written Users Guide, and it doesn't want to install.

Incidentally I have obscured the address of the correspondent here,
and am now doing so on other lists that are searchable via the usual
methods.
-- 
-
Gregg C Levine gregg.drw...@gmail.com
"This signature was once found posting rude
 messages in English in the Moscow subway."

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

Re: Problems starting sshd as a service on cygwin 1.7.1

[Myron Flickner]

Thanks for catching the typeo - it's cygrunsrv. 

sshd was installed as I outlined in the original posting. 

http://cygwin.com/ml/cygwin/2010-01/msg00893.html

 imaging away / flick



- Original Message 
From: Gregg Levine 
To: cygwin@cygwin.com
Sent: Tue, January 26, 2010 3:56:41 PM
Subject: Re: Problems starting sshd as a service on cygwin 1.7.1

On Tue, Jan 26, 2010 at 6:40 PM, Myron Flickner  wrote:
> Problem remains - If I repeat the cgyrunsrv -S sshd command eventually it 
> works.
>
> Disabling Symantec Client Firewall didn't fix this.
>
> I've attached the cygcheck.out file.Is there any other tracing I can do ?
>
>  imaging away / flick
>
>
>
Hello!
While the experts are sorting out your file, I have one comment and
one or two questions.

First the comment, check the spelling on that one, it isn't "cgyrunsrv
-S sshd", it happens to be "cygrunsrv -S sshd".

And now the questions, How did you originally install the service for
ssh? And what were those steps?

I have followed the majority of the ones listed in the rather well
written Users Guide, and it doesn't want to install.

Incidentally I have obscured the address of the correspondent here,
and am now doing so on other lists that are searchable via the usual
methods.
-- 
-
Gregg C Levine gregg.drw...@gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."

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


  

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

Bug: cygport fails when the working directory pathname contains spaces

[Steven Monai]

Hi folks,

Consider this command line transcript:
--
$ uname -a
CYGWIN_NT-5.1 hostname 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin

$ cygcheck -c cygport
Cygwin Package Information
Package  VersionStatus
cygport  0.9.80-1   OK

$ pwd
/home/steve/My Documents/bglibs

$ ls
bglibs-1.106-1.cygport

$ cygport bglibs-1.106-1.cygport download
/usr/bin/cygport: line 444: [: /home/steve/My: binary operator expected
/usr/bin/cygport: line 450: /home/steve/My: No such file or directory

--
Workaround: Move the working dir to a path not containing spaces.

Best regards,
-SM
--

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

cd /cygdrive hangs for some time.

[Ram Kal]

Hi,

I have a new problem with latest Cygwin installation
(1.7.1(0.218/5/3)). Most of the times I wanted to cd to C Drive, the
command hangs for few seconds and then completes. Also noticed that
once i am in /cygdrive/c and do a 'ls -l' command, same thing happens.

I have attached the point in the strace log where the commands hangs:

   25  213581 [main] ls 3332 normalize_posix_path: /cygdrive/ =
normalize_posix_path (/cygdrive/c/..)
   26  213607 [main] ls 3332 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive)
   44  213651 [main] ls 3332 set_flags: flags: binary (0x2)
   45  213696 [main] ls 3332 mount_info::conv_to_win32_path: src_path
/cygdrive, dst C:\cygwin\cygdrive, flags 0x3000A, rc 0
  148  213844 [main] ls 3332 build_fh_pc: fh 0x6120EA84
   28  213872 [main] ls 3332 stat_worker: (\??\C:\cygwin\cygdrive,
0x22C800, 0x6120EA84), file_attributes 17
   27  213899 [main] ls 3332 fhandler_base::fstat: here
25526673 25740572 [main] ls 3332 stat_worker: 0 =
(\??\C:\cygwin\cygdrive, 0x22C800)



Any Help is appeciated.

Thanx
Ramana.

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

Suggestion: relative path for cygstart

[Ken Hirsch]

Older versions of cygstart did not replace the file names with absolute 
windows paths. This was better since the ShellExecute function will 
search the path for a command. And, if it doesn't find it in the path, 
it will look in the registry. So you can 'cygstart calc', 'cygstart 
winword', 'cygstart services.msc', etc.


This can be accomplished by changing
 CCP_POSIX_TO_WIN_W
to
 CCP_POSIX_TO_WIN_W|CCP_RELATIVE
the two places it appears.

Interestingly, ShellExecute also accepts certain non-filename strings 
for "shell namespace objects".


For example:

Drives (My computer)
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

Control Panel
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}

You can try these out with the Run command on the Windows start menu or 
the CMD.EXE  START command.


This last one doesn't work in cygstart even after the CCP_RELATIVE 
change is made. This is not because of any bug in cygstart, though, so 
I'll save it for another email.


Ken Hirsch


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

re: Cygwin Vista svn problem STATUS_ACCESS_VIOLATION

[Richard Stanton]

Following up on Mark MacVicar's recent email about getting a stack dump using 
svn from a DOS prompt, I have exactly the same problem (Cygwin 1.7.1 running 
under Vista). Here's some more info: 

a. If the repository is accessed at http..., svn works fine from the DOS prompt.

b. When I switched so that I needed to access the (same) repository using 
https:..., the crash started:

C:\scratch>svn co https://[host]/[repository]

  9 [main] svn 3460 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   1342 [main] svn 3460 open_stackdumpfile: Dumping stack trace to 
svn.exe.stackdump
  9 [main] svn 3460 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   1342 [main] svn 3460 open_stackdumpfile: Dumping stack trace to 
svn.exe.stackdump

c. If I run the same command from a Bash prompt (created using the default 
Cygwin icon), svn works fine.

d. I thought it might be a path issue, but the same thing happens when I make 
c:\cygwin\bin the first item in my DOS path.

Thanks for any suggestions.

Richard Stanton

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

Re: 1.7.1 "Bad Address" when running cmd.exe on 64 bit windows server 2008

[jenniferlee]

Wow, thank you so much, that was very fast!  

Is there a way I can refer my customers to this patch? Or should I put the 
workarounds in my code for now until this is in an official release?

I appreciate all the help with the workarounds, that got me going again, but at 
this point I either need to ship a patch on my end with the work around, or 
somehow get my end users to put the cygwin patch on, but I am not sure how to 
do that?

Thanks for all the help,

Jennifer


 Corinna Vinschen  wrote: 
> On Jan 23 12:03, Corinna Vinschen wrote:
> > On Jan 22 19:52, Dave Korn wrote:
> > > On 22/01/2010 19:10, Cooper, Karl (US SSA) wrote:
> > > >>  jenniferlee@ wrote:
> > > 
> > > >>> administra...@nc042046 ~ $ cmd.exe /c 'mkdir C:\WINDOWS\temp' -bash:
> > > >>> /cygdrive/c/Windows/system32/cmd.exe: Bad address
> > > >>> 
> > > > I get the same result you do when I use "/c" (lower case c), but the
> > > > command is processed as expected when I use "/C" (upper case C).
> > > 
> > >   I get the same, and found a different workaround: it works by using 
> > > "cmd"
> > > instead of "cmd.exe".
> > 
> > If nobody beats me to it, I'll look into that one next week.
> 
> Should be fixed in CVS now.
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader  cygwin AT cygwin DOT com
> Red Hat
> 
> --
> 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
> 


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

I suggest changing the default application to mintty

[Clinton Goudie-Nice]

I've experienced a variety of people who have used Cygwin, and then
been frustrated by the inability to scale the window or cut and paste
effectively. Often I ask if they've used mintty and they don't even
know what I'm talking about since it's not installed by default, and
even if it were, they would probably still use the Cygwin app
installed on the desktop.

I'd like to humbly suggest changing the default application to mintty.
It gives a much more flexible feel to cygwin, and generally makes the
user experience more friendly.

Clint Goudie-Nice

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

Re: Bug: cygport fails when the working directory pathname contains spaces

[Yaakov (Cygwin/X)]

On 26/01/2010 20:09, Steven Monai wrote:

$ pwd
/home/steve/My Documents/bglibs


This is not a bug in cygport per se.  Spaces in paths is just a bad idea 
when you're dealing with shell scripts and you will find all sorts of 
breakage as a result (as has already been well documented on this list).



Yaakov

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

Re: Bug: cygport fails when the working directory pathname contains spaces

[Lee Rothstein]

Steven Monai wrote:

Hi folks,

Consider this command line transcript:
--
$ uname -a
CYGWIN_NT-5.1 hostname 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin

$ cygcheck -c cygport
Cygwin Package Information
Package  VersionStatus
cygport  0.9.80-1   OK

$ pwd
/home/steve/My Documents/bglibs

$ ls
bglibs-1.106-1.cygport

$ cygport bglibs-1.106-1.cygport download
/usr/bin/cygport: line 444: [: /home/steve/My: binary operator expected
/usr/bin/cygport: line 450: /home/steve/My: No such file or directory

--
Workaround: Move the working dir to a path not containing spaces.


Or, better still, mount the ensppaced path to an alias sans, spaces.

E.g., /etc/fstab entry:

c:/home/steve/My\040Documents /zwup/steves_docs  some_fs binary 0 0

'zwup'? Z -- end of the alphabet, keeps them out of the way for find; WUP -- 
windows ugly paths

then, target directory is  /zwup/steves_docs/bglibs



C:/Program\040Files\040(x86)/ACD\040Systems/ACDSee/10.0 /zup/ACDSee_10 
some_fs binary 0 0


Best regards,
-SM
--

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





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

Re: Bug: cygport fails when the working directory pathname contains spaces

[Steven Monai]

On 2010/01/26 8:42 PM, Yaakov (Cygwin/X) wrote:
> On 26/01/2010 20:09, Steven Monai wrote:
>> $ pwd
>> /home/steve/My Documents/bglibs
> 
> This is not a bug in cygport per se.  Spaces in paths is just a bad idea
> when you're dealing with shell scripts and you will find all sorts of
> breakage as a result (as has already been well documented on this list).

Imagine if a program like 'cp' failed because the current working
directory has a pathname that contains spaces. You'd probably agree with
me that 'cp' had a rather serious flaw, wouldn't you?

I stand by my original report. This is a bug. Not a serious show-stopper
by any stretch, but a bug, nonetheless.

When I find the time and motivation, I may try my hand at fixing it
myself. I'll report back with patches if I do.

-SM
--

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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Kazuhiro Fujieda]

>>> On Tue, 26 Jan 2010 18:06:15 +0100
>>> Corinna Vinschen said:

> As for the default charset, now that we get extended NLS
> support, there are packages out there which have messages
> files for ja_JP encoded in eucJP.  These are not shown
> correctly if SJIS is the default.

The runtime library of NLS convert messages encoded in EUC-JP to
the character encoding obtained by nl_langinfo(CODESET). We can
properly see Japanese messages.

> > There is no difference between SJIS and eucJP on Cygwin
> >  command line for the sake of the implementation of i18n API.
> >  If there is any difference, we should correct it. To change
> > the default to eucJP isn't adequate.
>
> I don't understand this one.

Andy said `Seems SJIS really isn't suited for Unix command line
use.' I said there is no problem, no difference with EUC-JP, and
no need to change the default.

> The difference is the character encoding which is compatible
> with other POSIX systems in the "ja_JP" locale when eucJP is
> the default.

The default character encoding in the Japanese locale has become
UTF-8 in other POSIX systems. In most of all Linux distributions,
the default is UTF-8. In OpenSolaris, the default is also UTF-8.
On the other hand, the default is SJIS in HP-UX.

I believe there is no need to change the default in Cygwin to EUC-JP.
-- 
Kazuhiro Fujieda 


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

'git commit' problem

[Sisyphus]

Hi,

This might be a general 'git' issue rather than something specific to 
Cygwin. (The only git I have used is Cygwin's git - version 1.5.4.)


When I try to 'git commit' my amendments I often get hit with "* trailing 
whitespace (line xxx)" errors.


Firstly, I'm wondering what's wrong with having whitespace at the end of a 
line ? Why should it prevent changes from being committed ?


Secondly, what's the best way to deal with this ? Can this check be easily 
disabled ?


Cheers,
Rob 



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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Andy Koppe]

2010/1/27 Kazuhiro Fujieda:
> Andy said `Seems SJIS really isn't suited for Unix command line
> use.' I said there is no problem, no difference with EUC-JP, and
> no need to change the default.

That comment primarily referred to standard SJIS, with its mappings of
the ASCII backslash and tilde codepoints to yen and overscore. This is
addressed by using MS's CP932 version instead.

Another issue is SJIS's use of bytes in the ASCII range as trailing
byte, which is bound to confuse programs that have been written
without considering that. Yes, any such programs should be considered
buggy, but they won't fix themselves.

But that's beside the point. The change is not due to SJIS's
shortcomings, but for the purpose of Unix/Linux compatibility. There's
no particular requirement on the Windows side that "ja_JP" should mean
SJIS, but there are Unix programs that assume that "ja_JP" means
eucJP.

Also, please remember that Cygwin's default locale is "C.UTF-8", i.e.
Japanese users (like everyone else) will be using UTF-8 by default,
not eucJP. The change only concerns users who explicitly set the
locale to "ja_JP". They will need to set it to "ja_JP.SJIS" instead to
stick with SJIS.


> The default character encoding in the Japanese locale has become
> UTF-8 in other POSIX systems. In most of all Linux distributions,
> the default is UTF-8. In OpenSolaris, the default is also UTF-8.

Are you saying that plain "ja_JP" without an explicit charset implies
UTF-8 there? Or are they setting the locale to "ja_JP.UTF-8"?


> I believe there is no need to change the default in Cygwin to EUC-JP.

Just to stress this again: Cygwin 1.7's default is and remains UTF-8.

Andy

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

Re: Please support CP932. (I have problem using subversion with SJIS)

[Kazuhiro Fujieda]

>>> On Tue, 26 Jan 2010 18:28:53 +
>>> Andy Koppe said:

> Another example is X11, which has its own locale system independent
> from Cygwin's. There, "ja_JP" implies eucJP already. This means that
> with LANG=ja_JP, xterm uses eucJP, while filenames and programs
> currently use the system's ANSI codepage, i.e. CP932 on Japanese
> systems. Result: mojibake. It does work correctly with
> LANG=ja_JP.SJIS.

You should set an appropriate alias in locale.aliases.

When the i18n framework in X11 was implemented, The default
character encoding in the Japanese locale wasn't necessarily
EUC-JP. I remember there was a conditional macro in the source
of locale.aliases to adjust it about 20 years ago.

The default encoding in the X11 locale should be adjusted to
the system locale. It is a natural way of solving this problem.
-- 
Kazuhiro Fujieda 


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