[ANNOUNCEMENT] [1.7] Updated: clisp-2.48-2

[Reini Urban]

I've updated clisp plus the subpackages
clisp-clx, clisp-gtk2 and clisp-gdi to 2.48-2, to fix the issues 
reported at http://cygwin.com/ml/cygwin/2009-08/msg00265.html


2.48-2
* chmod +x /usr/lib/clisp-2.48/full*/svm.dll
* fixed wrong libdb4.6 dependency to libdb4.5
* fixed clisp-gdi.src.patch

Old 2.48-1 announcement:

clisp-gtk2 was re-added and includes now also dbus.
clisp-gdi is a modern package (case-sensitive and case-inverted),
and now hosted at http://code.google.com/p/clisp-gdi/
Depends on libsigsegv1 with Eric Blake's fixes for the SEH chain corruption.
No jit, no multithreading.

Release focus:
bugfixes and enhancements

./configure --fsstnd=redhat --with-ffcall \
  --with-module=rawsock --with-module=dirkey --with-module=wildcard \
  --with-module=bindings/win32 \
  --with-module=berkeley-db --with-module=pcre --with-module=postgresql\
  --with-module=fastcgi --with-module=libsvm --with-module=gdbm \
  --with-module=zlib --with-module=clx/new-clx --with-module=gtk2 \
  --with-module=dbus \
  --with-module=gdi --prefix=/usr --cbc build
Cygwin Changes:
2.48-1 (for 1.7)
* re-enabled gtk2
* added dbus to -gtk2 package
* added wildcard module to full
* gdi fixes and new functions, still alpha. See
http://code.google.com/p/clisp-gdi/
* minor modprep and build patches added
* removed fix_iconv build hack
* added libsigsegv1 dependency
* revised required dependencies
* disabled stripping to enable (disassemble)

http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS

Changes: Multithreading is mostly usable on most platforms, although
officially it is still experimental.
clisp.m4 has been added for packages that rely on CLISP to detect the
desired... version. A few bugs have been fixed.

2.48 (2009-07-28)
=

Important notes
---

* Multiple threads of execution are now experimentally supported
  (not ready for prime time yet).
  Thanks to  Vladimir Tzankov .
  See  for details.

* Module libsvm has been upgraded to the upstream version 2.89.
  See  for details.

* Module Berkeley-DB now supports Berkeley DB 4.7.
  (older versions 4.* are, of course, still supported).
  See  for details.

* Module readline now supports readline 6.0.
  (older versions 5.* are, of course, still supported).
  See  for details.

* Passing :EXECUTABLE 0 to EXT:SAVEINITMEM results in an executable
  image which delegates processing of all the usual CLISP command line
  options to the :INIT-FUNCTION.
  See  for details.

* Driver clisp accepts "-b" to print the installation directory.
  See  for
details.

* Add file clisp.m4 so that the packages which use CLISP can check
  whether it is properly installed and has the required version.

* POSIX:COPY-FILE now accepts :METHOD :HARDLINK-OR-COPY.
  See  for details.

* New function POSIX:WAIT calls waitpid or wait4.
  See  for details.

* New function EXT:TRIM-IF removes leading and trailing matches.
  See  for
details.

* New user command "LocalSymbols" (abbreviated ":ls").
  See 
  for details.

* Commands "add" and "create" replace "add-module-set",
"add-module-sets" and
  "create-module-set" in clisp-link.
  See  for details.

* Bug fixes:
  + Better support of :START and :END arguments in NEW-CLX. [ 2159172 ]
  + Fix LOAD-LOGICAL-PATHNAME-TRANSLATIONS when *LOAD-PATHS* contains
wild pathnames (introduced in 2.47). [ 2198109 ]
  + Module NEW-CLX now has the XLIB:QUEUE-EVENT function,
implemented by Philippe Brochard .
  + Extend the domain of LOG to larger BIGNUMs and RATIOs. [ 1007358 ]
  + Avoid a segfault on (EXPT  ). [ 2807311 ]
  + Fix interaction of finalizers and weak objects. [ 1472478 ]

* ANSI compliance:
  + Implement the ANSI (IGNORE #'FUNCTION) declaration.

2.47 (2008-10-23)
=

Important notes
---

* New module DBUS interfaces to the D-Bus message bus system.
  See  for details.

* New function EXT:PROBE-PATHNAME can figure out whether the existing
  pathname refers to a file or a directory.
  See  for details.

* New function EXT:CANONICALIZE lets you easily canonicalize a value
  before processing it.
  See  for
details.

* New user variable CUSTOM:*REOPEN-OPEN-FILE* controls CLISP behavior
  when opening an already open file.
  See 

Re: Perl bug (was Re: [1.7] cygwin allows writing to readonly files)

[Reini Urban]

2009/8/11 Reini Urban:
> 2009/8/10 Corinna Vinschen:
>> On Aug 10 20:11, Alexey Borzenkov wrote:
>>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>>> Vinschen wrote:
>>> > That's a bug in your testsuite.  I assume you're running the tests as
>>> > administrator, right?  Administrators have the right to write to all
>>> > files, even R/O files, according to POSIX rules.  Your test would fail
>>> > on Linux as well, if you're running it as root.
>>>
>>> Well, it's not my testsuite, but yes, I'm running under administrator
>>> account. But it makes me wonder, how does it work? Do you change ACLs
>>> temporarily?
>>
>> No.  It's a "user privileges" thingy.  See
>> http://msdn.microsoft.com/en-us/library/aa379306%28VS.85%29.aspx
>>
>> The SE_BACKUP_NAME and SE_RESTORE_NAME privileges are in the
>> administrator's user token, but they are not enabled by default.  Cygwin
>> just enables them at startup time, if they are available in the user
>> token.  Therefore, a Cygwin process has the usual POSIX-like permissions
>> for admin users.  It's no magic which isn't available to any other
>> native Win32 application.
>>
>>> Anyway, it means there is a bug in perl, because on Linux:
>>>
>>> r...@kitsu:~# touch test.txt
>>> r...@kitsu:~# chmod 0444 test.txt
>>> r...@kitsu:~# perl -e 'print "writable\n" if -w "test.txt"'
>>> writable
>>>
>>> On Cygwin 1.7 perl thinks that the file is not writable.
>>
>> Indeed.  Checking with strace I found that the test is the same on Linux
>> and Cygwin.  In both cases perl uses stat(), and the returned permissions
>> are the same (0444).  Further experimenting shows that perl has a
>> hardcoded uid == 0 test which must obviously fail on Cygwin.  If I change
>> the user's uid to 0, the string "writable" is printed by the above command.
>>
>> That's a bug in perl.  There are other OSes out there which have
>> root-like permissions for non-0 uids.  Perl should use the access()
>> function to check for read/write/execute permissions, which always
>> returns the correct result independent of the uid of the current user.
>
> Thanks.
> I'll carry it along to p5p, but it will definitely not appear in
> upstream 5.10.1
> because this gate is already closed.
> Even a horrible performance problem with
> File::Spec::Cygwin::case_tolerant was not fixed.
>
> But I work on a fix to be included in blead and in my cygwin package.

Bug confirmed too early. It's actually defined and described this way.
access() is not used for performance reasons. See perldoc perlfunc -X

If you are using ACLs, there is a pragma called C that may
produce more accurate results than the bare stat() mode bits.
When under the C the above-mentioned filetests
will test whether the permission can (not) be granted using the
access() family of system calls.  Also note that the C<-x> and C<-X> may
under this pragma return true even if there are no execute permission
bits set (nor any extra execute permission ACLs).  This strangeness is
due to the underlying system calls' definitions. Note also that, due to
the implementation of C, the C<_> special
filehandle won't cache the results of the file tests when this pragma is
in effect.  Read the documentation for the C pragma for more
information.

$ ./perl -e 'print "writable\n" if -w "test.txt"'

$ ./perl -e 'use filetest "access"; print "writable\n" if -w "test.txt"'
writable

I can turn on access checks easily for CYGWIN but cygwin perl is already
slow enough, so I will not do that.

Changing the uid==0 check to check the Administrators gid is more promising.
i.e.
--- doio.c.orig 2009-04-18 19:17:04.0 +0200
+++ doio.c  2009-08-11 04:46:09.34375 +0200
@@ -1918,7 +1918,11 @@
  return (mode & statbufp->st_mode) ? TRUE : FALSE;

 #else /* ! DOSISH */
+# ifndef __CYGWIN__
 if ((effective ? PL_euid : PL_uid) == 0) { /* root is special */
+# else
+if ((effective ? PL_egid : PL_gid) == 544) { /* member of
Administrators? */
+# endif
if (mode == S_IXUSR) {
if (statbufp->st_mode & 0111 || S_ISDIR(statbufp->st_mode))
return TRUE;

but this didn't help me, because Administrators is not my first group.
So I call this a known limitation for all ACL aware filesystems.
-- 
Reini Urban
http://phpwiki.org/   http://murbreak.at/

--
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: [RFC] jpeg library

[Charles Wilson]

Charles Wilson wrote:

> OK...new plan:  jpeg-v7 will be released for cygwin-1.7 only, using
> gcc4/dw2/shared-libgcc only, and will have the name "cygjpeg-7.dll".  It
> will NOT have lossless jpeg support.
> 
> I'll do this soon.

I've just posted, for 1.7 only, an update for libjpeg to jpeg v7. This
version no longer supports lossless jpeg, and therefore no longer
requires ill-behaved client packages that manipulate "private" jpeg data
structures to take special care when compiling on cygwin.

However, this means that if you maintain a client package that DOES
currently take special care on cygwin, to accommodate our old lossless
jpeg support, then your build may break NOW, until you remove those
modifications from your package.

However, contrary to the statement above, libjpeg7 was compiled using
gcc3, not gcc4/dw2/shared-libgcc.  A later update will switch to gcc4
after gcc4 goes "gold".

I've also uploaded (for cygwin-1.7 only) a "backwards compatibility" DLL
package, libjpeg62, containing the old-style DLL -- so existing
applications will continue to work properly.

Finally, I've uploaded (for both cygwin-1.5 and cygwin-1.7) a new
version of the tiff packages:

1) cygwin-1.7: tiff-3.8.2-11 compiled against the new libjpeg7, as a
sort of 'smoke test'.  Also, imported Debian fixes for CVE-2009-2285 and
CVE-2009-2347.

2) cygwin-1.5: tiff-3.8.2-5 recompiled to bring in Debian fixes for
CVE-2009-2285 and CVE-2009-2347.

--
Chuck

--
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: {tiff/libtiff5/libtiff-devel/tiff-doc/tiff-opengl}-3.8.2-5

[Charles Wilson]

The tiff package provides libraries and utilities for manipulating
TIFF image files.

This is a security update.

[[ compiled using gcc-3.4.4-999 ]]

This release is specific to cygwin-1.5. It imports a number of new
security patches from Debian.

CHANGES (since 3.8.2-4)

o Update to debian patchset 3.8.2-13
  - Fixes CVE-2009-2285
  - Fixes CVE-2009-2347
o Remove cygwin from requires: in hint files; rely on sourceware
  infrastructure to add it back.

-- 
Charles Wilson
volunteer tiff maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
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] [1.7] Updated: {tiff/libtiff5/libtiff-devel/tiff-doc/tiff-opengl}-3.8.2-11

[Charles Wilson]

The tiff package provides libraries and utilities for manipulating
TIFF image files.

This is a security update.

[[ compiled using gcc-3.4.4-999 ]]

This release is specific to cygwin-1.7. It is compiled against the
(cygwin-1.7-only) libjpeg7 release, and imports a number of new security
patches from Debian.

CHANGES (since 3.8.2-10)

o Rebuild against libjpeg7
o Update to debian patchset 3.8.2-13
  - Fixes CVE-2009-2285
  - Fixes CVE-2009-2347
o Remove cygwin from requires: in hint files; rely on sourceware
  infrastructure to add it back.
o Fix documentation path to match cygwin-1.7 standards.

Charles Wilson
volunteer tiff maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
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] [1.7] Updated: {jpeg/libjpeg-devel}-7-10, NEW: libjpeg7-7-10

[Charles Wilson]

The jpeg package contains the Independent JPEG Group's libjpeg library
and various utility programs for manipulating jpeg files and images.

This is a major update to the new upstream release. Also, support for
"lossless jpeg" has been removed (see below).  Because these changes
break the ABI, the DLL has a new name and the old cygjpeg-62.dll is
provided in a separate, backwards-compatibility package.

[[ compiled using gcc-3.4.4-999 ]]
Because gcc-4.x for cygwin is still in beta status, this version of
jpeg was compiled using the current version of gcc as indicated above.
I'll release a new version, with gcc4 and all the goodies (dw2 exceptions,
shared-libgcc, etc) when cygwin's gcc-4.x is officially promoted.

This release is specific for cygwin-1.7. There will be no jpeg-7 release
for cygwin-1.5.

CHANGES (since 6b-20)

o Update to latest upstream release
o Remove "lossless jpeg" support.
o Update hint files to reflect correct requirements:
  don't explicitly specify cygwin, and we do not actually
  require libpng or libz.

About Lossless JPEG:

  Lossless jpeg support has been removed. Lossless jpeg was never
  accepted upstream, and has been a "local" patch in the cygwin version
  of jpeg for years (since the first "Net Release" after cygwin B20.1).

  The patch modified certain data structures that are marked "private"
  in the jpeg headers, but they *are* in the headers.  Therefore, many
  clients have manipulated those "private" structures directly.  To
  interoperate with cygwin's lossless-patched version, they had to make
  certain accomodations:
  http://cygwin.com/ml/cygwin/2005-07/msg01005.html
  So the question becomes, why was lossless jpeg support added to
  cygwin's official version of libjpeg in the first place?  I added it
  because I needed it to deal with certain medical imagery, and frankly
  was unaware at the time that changing "private" data structures would
  really affect anybody else.

  Isn't that what "private" means?

  Well, I no longer need to deal with that sort of imagery, and
  "private" never really was very private, and it DID cause lots of
  people grief.  And, our build environment for packages is much nicer
  now than it was in the early days, so any Joe who needs lossless jpeg
  can easily build it themselves.  So, it's nice to finally get rid of
  the lossless jpeg patch.

  The downside of removing this, is that over over the years those
  other clients have added lots of workarounds to accommodate cygwin's
  jpeg library. With this release of libjpeg, those clients no longer
  need those workarounds -- but until they too remove their workarounds,
  building those clients will break on cygwin again!

  However, because the DLL name (analogous to the linux SONAME) has
  been changed in this release, existing applications will continue
  to operate correctly, relying on the (old) cygjpeg-62.dll. It's
  only newly-compiled applications that will use the new cygjpeg-7.dll
  and may need to reverse their earlier accomodations for cygwin's
  lossless jpeg.


-- 
Charles Wilson
volunteer jpeg maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
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] [1.7] Updated: libjpeg62-6b-21

[Charles Wilson]

The jpeg package contains the Independent JPEG Group's libjpeg library
and various utility programs for manipulating jpeg files and images.

This is a backwards-compatibility package, now that the jpeg-7 library
has been released.

[[ compiled using gcc-3.4.4-999 ]]

CHANGES (since 6b-20)

o Provide only the cygjpeg-62.dll for backwards-compatibiltiy

-- 
Charles Wilson
volunteer jpeg maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


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

libsigsegv-2.6+ vs 2.7 on cygwin

[Reini Urban]

Eric,
Can you please update your git repo at git://repo.or.cz/libsigsegv/ericb.git
to latest libsigsegv-2.7 so that I can roll a 2.7+
Or should I rather ignore 2.7 totally? I see no cygwin relevant
changes in 2.7 at all.
Bruno did not include your cygwin fixes for the SEH chain corruption into 2.7.

Bruno,
Can we please have eric's cygwin fixes in a next update somewhen?

-- Forwarded message --
From: Reini Urban 
Date: 2009/8/7
Subject: [1.7] Updated: libsigsegv{1}-2.6+-1
To: cygwin-annou...@cygwin.com


I've promoted the experimental libsigsegv 2.6+-1 to current.
I need it for the upcoming clisp release, though I got no feedback yet
upstream if Eric' fixes will be eventually in the next release 2.7.

Eric Blake fixed the SEH chain corruption in libsigsegv for 2.6+.
The DLL revision is bumped from 0 to 1, so you can now change your
requires to libsigsegv1.
libsigsegv0 contains the old sources.

See http://cygwin.com/ml/cygwin/2009-07/msg00881.html for the problems fixed.

It's a small library for handling page faults in user mode.
A page fault occurs when a program tries to access to a region of memory
(heap or stack) that is currently not available.
It is mainly required for clisp for generational garbage collection,
m4 also uses for stack overflow protection.

Canonical homepage:
 http://libsigsegv.sourceforge.net/

Canonical download:
 git clone git://repo.or.cz/libsigsegv/ericb.git
 which is a branch of the official git://git.sv.gnu.org/libsigsegv.git



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://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Reini Urban

--
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: Perl bug (was Re: [1.7] cygwin allows writing to readonly files)

[Reini Urban]

2009/8/10 Corinna Vinschen:
> On Aug 10 20:11, Alexey Borzenkov wrote:
>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>> Vinschen wrote:
>> > That's a bug in your testsuite.  I assume you're running the tests as
>> > administrator, right?  Administrators have the right to write to all
>> > files, even R/O files, according to POSIX rules.  Your test would fail
>> > on Linux as well, if you're running it as root.
>>
>> Well, it's not my testsuite, but yes, I'm running under administrator
>> account. But it makes me wonder, how does it work? Do you change ACLs
>> temporarily?
>
> No.  It's a "user privileges" thingy.  See
> http://msdn.microsoft.com/en-us/library/aa379306%28VS.85%29.aspx
>
> The SE_BACKUP_NAME and SE_RESTORE_NAME privileges are in the
> administrator's user token, but they are not enabled by default.  Cygwin
> just enables them at startup time, if they are available in the user
> token.  Therefore, a Cygwin process has the usual POSIX-like permissions
> for admin users.  It's no magic which isn't available to any other
> native Win32 application.
>
>> Anyway, it means there is a bug in perl, because on Linux:
>>
>> r...@kitsu:~# touch test.txt
>> r...@kitsu:~# chmod 0444 test.txt
>> r...@kitsu:~# perl -e 'print "writable\n" if -w "test.txt"'
>> writable
>>
>> On Cygwin 1.7 perl thinks that the file is not writable.
>
> Indeed.  Checking with strace I found that the test is the same on Linux
> and Cygwin.  In both cases perl uses stat(), and the returned permissions
> are the same (0444).  Further experimenting shows that perl has a
> hardcoded uid == 0 test which must obviously fail on Cygwin.  If I change
> the user's uid to 0, the string "writable" is printed by the above command.
>
> That's a bug in perl.  There are other OSes out there which have
> root-like permissions for non-0 uids.  Perl should use the access()
> function to check for read/write/execute permissions, which always
> returns the correct result independent of the uid of the current user.

Thanks.
I'll carry it along to p5p, but it will definitely not appear in
upstream 5.10.1
because this gate is already closed.
Even a horrible performance problem with
File::Spec::Cygwin::case_tolerant was not fixed.

But I work on a fix to be included in blead and in my cygwin package.
-- 
Reini Urban

--
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: Cron jobs visible

[Mark J. Reed]

On Mon, Aug 10, 2009 at 5:17 PM, Christopher Faylor wrote:
> Actually, I meant Cgywin 1.7.  Sorry for the cornfusion.

cgf apologizes!  In writing!  Alert the media!

:)

-- 
Mark J. Reed 

--
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: Cron jobs visible

[Christopher Faylor]

On Mon, Aug 10, 2009 at 04:44:09PM -0400, Larry Hall (Cygwin) wrote:
>On 08/10/2009 04:07 PM, Ralph Hempel wrote:
>> Christopher Faylor wrote:
>>> On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
 On 08/10/2009 12:44 PM, Corinna Vinschen wrote:

 

> And there's no way back after an update. But as I noted in my zillion
> (apparently unread) test announcements, it's no problem to run 1.5 and
> 1.7 installations in separate directories side-by-side.
 I don't know about anyone else, but I plan to run 1.5 and 1.7 together.
 That will give me, effectively, Cygwin 3.2, which I can't wait to try
 out! At least I think that's what Corinna's announcements said... ;-)
>>>
>>> Good point but I think Corinna's announcement said something about
>>> formatting my hard drive so I'm not even going to think about installing
>>> Cygwin 7.1 until I get a new computer.
>>
>> I just got a new computer - and it doesn't even have switches on the
>> front panel. I am so disappointed.
>
>
>
>What?  No switches on new computers?  What kind of progress is that?
>
>> Wait a minute - what's this about Cygwin 7.1? Is that the new version
>> for Windows 7?
>
>I think Chris is confused... or mean.  I get those two mixed up.  But I
>heard a rumor that MS is secretly using Cygwin 1.7 in Windows 7...

Actually, I meant Cgywin 1.7.  Sorry for the cornfusion.

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: Cron jobs visible

[Larry Hall (Cygwin)]

On 08/10/2009 04:07 PM, Ralph Hempel wrote:

Christopher Faylor wrote:

On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:

On 08/10/2009 12:44 PM, Corinna Vinschen wrote:




And there's no way back after an update. But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 installations in separate directories side-by-side.

I don't know about anyone else, but I plan to run 1.5 and 1.7 together.
That will give me, effectively, Cygwin 3.2, which I can't wait to try
out! At least I think that's what Corinna's announcements said... ;-)


Good point but I think Corinna's announcement said something about
formatting my hard drive so I'm not even going to think about installing
Cygwin 7.1 until I get a new computer.


I just got a new computer - and it doesn't even have switches on the
front panel. I am so disappointed.




What?  No switches on new computers?  What kind of progress is that?


Wait a minute - what's this about Cygwin 7.1? Is that the new version
for Windows 7?


I think Chris is confused... or mean.  I get those two mixed up.  But I
heard a rumor that MS is secretly using Cygwin 1.7 in Windows 7...

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Cron jobs visible

[Ralph Hempel]

Christopher Faylor wrote:

On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:

On 08/10/2009 12:44 PM, Corinna Vinschen wrote:




And there's no way back after an update.  But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 installations in separate directories side-by-side.

I don't know about anyone else, but I plan to run 1.5 and 1.7 together.
That will give me, effectively, Cygwin 3.2, which I can't wait to try
out!  At least I think that's what Corinna's announcements said... ;-)


Good point but I think Corinna's announcement said something about
formatting my hard drive so I'm not even going to think about installing
Cygwin 7.1 until I get a new computer.


I just got a new computer - and it doesn't even have switches on the
front panel. I am so disappointed.

Wait a minute - what's this about Cygwin 7.1? Is that the new version
for Windows 7?

Ralph


--
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: Cron jobs visible

[Christopher Faylor]

On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
>On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
>
>
>
>> And there's no way back after an update.  But as I noted in my zillion
>> (apparently unread) test announcements, it's no problem to run 1.5 and
>> 1.7 installations in separate directories side-by-side.
>
>I don't know about anyone else, but I plan to run 1.5 and 1.7 together.
>That will give me, effectively, Cygwin 3.2, which I can't wait to try
>out!  At least I think that's what Corinna's announcements said... ;-)

Good point but I think Corinna's announcement said something about
formatting my hard drive so I'm not even going to think about installing
Cygwin 7.1 until I get a new computer.

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: [1.7] cygwin allows writing to readonly files

[Dave Korn]

Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
>> Anyway, it means there is a bug in perl, because on Linux:
> 
> On second though, it is actually bug in Cygwin. Programs and libraries expect
> superuser behavior only when user id is zero, which is clearly not the case
> in Cygwin 1.7.

http://www.opengroup.org/onlinepubs/95399/xrat/xbd_chap03.html

> Superuser*
> 
> This concept, with great historical significance to UNIX system users, has
> been replaced with the notion of appropriate privileges.

  This would seem to imply that it is permitted for there to be users other than
uid 0 with "appropriate" privileges.  Programs should not be trying to
second-guess the OS about the privs of a uid, they should ask the access()
function and find out.

cheers,
  DaveK

--
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: Perl bug (was Re: [1.7] cygwin allows writing to readonly files)

[Alexey Borzenkov]

On Mon, Aug 10, 2009 at 8:40 PM, Corinna
Vinschen wrote:
> That's a bug in perl.  There are other OSes out there which have
> root-like permissions for non-0 uids.  Perl should use the access()
> function to check for read/write/execute permissions, which always
> returns the correct result independent of the uid of the current user.

Ah, so it is actually possible on other OSes, I didn't know that. Then
maybe you're right.

Thanks for clarifying.

--
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: Cron jobs visible

[Larry Hall (Cygwin)]

On 08/10/2009 12:44 PM, Corinna Vinschen wrote:




And there's no way back after an update.  But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 installations in separate directories side-by-side.


I don't know about anyone else, but I plan to run 1.5 and 1.7 together.
That will give me, effectively, Cygwin 3.2, which I can't wait to try
out!  At least I think that's what Corinna's announcements said... ;-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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] cygwin allows writing to readonly files

[Alexey Borzenkov]

On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
> Anyway, it means there is a bug in perl, because on Linux:

On second though, it is actually bug in Cygwin. Programs and libraries
expect superuser behavior only when user id is zero, which is clearly
not the case in Cygwin 1.7. I think that maybe only local
administrator account should be assigned user id 0, and that only
local administrator should be allowed reading/writing files that it
has no access to.

--
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: Can't execute scripts from a samba share with 1.7

[Corinna Vinschen]

On Aug 10 19:04, Corinna Vinschen wrote:
> On Aug 10 17:42, Jon TURNEY wrote:
> > I also have this problem in it's second (noacl) form.  With this mount
> >
> > //necker/jon on /home/jon type smbfs (binary,exec,noacl,user)
> >
> > running the t.sh test script fails in a directory on this mount
> >
> > j...@byron ~
> > $ ls -al t.sh
> > -rwxr-xr-x 1 Jon None 19 2009-08-06 15:46 t.sh
> >
> > j...@byron ~
> > $ ./t.sh
> > -bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
> >
> > but works fine in a different directory
> 
> This is really strange.  The bad interpreter message means that
> bash could not start /bin/sh.  I can only reproduce this effect
> if I chmod -x /bin/sh.  Did you create an strace and tried to
> see what happens?

Never mind, I can reproduce it.  I'll have a look into it.


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

[ANNOUNCEMENT] Updated: run-1.1.11-1

[Charles Wilson]

The run package provides a simple application to launch console programs
with their console hidden.

[[ compiled using gcc-3.4.4-999 ]]

CHANGES since run-1.1.10

* New maintainer (Charles Wilson took over from Alexander Gottwald)
* Updated build machinery
* Added patch to support invisible consoles on Windows 7 (Corinna Vinschen)
* Modified invisiconsole mechanism on cygwin-1.5/WinXP+ (Corinna Vinschen)
* Remove explicit requires: cygwin; rely on sourceware infrastructure
  to add it back.

-- 
Charles Wilson
volunteer run maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
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] [1.7] Updated: run-1.1.11-10

[Charles Wilson]

The run package provides a simple application to launch console programs
with their console hidden.

[[ compiled using gcc-3.4.4-999 ]]

CHANGES since run-1.1.10

* Fork for cygwin-1.7 packaging. Underlying source branch will occur
  later, with 1.2.x.
* New maintainer (Charles Wilson took over from Alexander Gottwald)
* Updated build machinery
* Added patch to support invisible consoles on Windows 7 (Corinna Vinschen)
* Modified invisiconsole mechanism on cygwin-1.5/WinXP+ (Corinna Vinschen)
* Remove explicit requires: cygwin; rely on sourceware infrastructure
  to add it back.

-- 
Charles Wilson
volunteer run maintainer for cygwin



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

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
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: Can't execute scripts from a samba share with 1.7

[Corinna Vinschen]

On Aug 10 17:42, Jon TURNEY wrote:
> On 06/08/2009 18:50, Nahor wrote:
>> Corinna Vinschen wrote:
>>> On Aug 5 13:40, Nahor wrote:
 If I mount with "noacl", I get a slightly different error but still
 no cigar:
 $ ./t.sh
 -bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
 $
>>> This only happens if your account doesn't have execute permissions for
>>> the interpreter, in this case /bin/sh. Is it possible that /bin/sh.exe
>>> has weird permission settings for some reason?
>>
>> The permissions on the interpreter are OK.
>> $ ls -l /bin/sh
>> -rwxr-xr-x 1 nahor Administrators 472064 Jul 1 18:20 /bin/sh
>> $
>>
>> For that matter, scripts running off the local disk run fine.
>>
>> Looks like the same problem of inconsistent account ID, setting the
>> permissions to 755 or running as the domain user fix the "bad
>> interpreter" error.
>
> I also have this problem in it's second (noacl) form.  With this mount
>
> //necker/jon on /home/jon type smbfs (binary,exec,noacl,user)
>
> running the t.sh test script fails in a directory on this mount
>
> j...@byron ~
> $ ls -al t.sh
> -rwxr-xr-x 1 Jon None 19 2009-08-06 15:46 t.sh
>
> j...@byron ~
> $ ./t.sh
> -bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
>
> but works fine in a different directory

This is really strange.  The bad interpreter message means that
bash could not start /bin/sh.  I can only reproduce this effect
if I chmod -x /bin/sh.  Did you create an strace and tried to
see what happens?


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: Cron jobs visible

[Corinna Vinschen]

On Aug 10 18:31, Thorsten Kampe wrote:
> * Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
> > On Aug 10 14:15, Thorsten Kampe wrote:
> > > * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > > > On Aug 10 12:57, Thorsten Kampe wrote:
> > > > > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > > > > the new forked cron process is visible in a console window. I
> > > > > suspect that this might be related to the new "Console Window Host"
> > > > > (conhost.exe) as I also get this window when I run screen inside a
> > > > > shell.
> > > > 
> > > > Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.  Use
> > > > Cygwin 1.7 instead.  It contains workarounds for a few really incredible
> > > > bugs introduced in Windows 7 in terms of console windows.  I reported 
> > > > two 
> > > > of them in the beta testing phase.  One of them has been only partially
> > > > fixed (and introduced a new one in the W7 32 bit), the other one hasn't
> > > > been fixed at all in RTM.
> > > 
> > > Thanks for the insight and background information. I'll probably wait 
> > > until 1.7 is out of beta and an "official" migration document is 
> > > released.
> > 
> > What "official" migration document?  There will be a release announcment
> > and that's it.
> 
> Something like "how to move from 1.5 to 1.7". Or will it be an automatic 
> process done via (and by) Setup.exe? Or will we have to do a "fresh 
> install" :-/ ?

There's an update option, but it will not be entirely bump-free.  For a
couple of reasons the installation will only copy system mount points
from the HKLM registry entries to the new /etc/fstab, but not your user
mount points from the HKCU registry entries to /etc/fstab.d/$USER.

And there's no way back after an update.  But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 installations in separate directories side-by-side.


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: Cron jobs visible

[Christopher Faylor]

On Mon, Aug 10, 2009 at 06:31:53PM +0200, Thorsten Kampe wrote:
>* Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
>>On Aug 10 14:15, Thorsten Kampe wrote:
>>>* Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
On Aug 10 12:57, Thorsten Kampe wrote:
>I upgraded to Windows 7 on Sunday and now whenever cron runs a job, the
>new forked cron process is visible in a console window.  I suspect that
>this might be related to the new "Console Window Host" (conhost.exe) as
>I also get this window when I run screen inside a shell.

Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.
Use Cygwin 1.7 instead.  It contains workarounds for a few really
incredible bugs introduced in Windows 7 in terms of console windows.  I
reported two of them in the beta testing phase.  One of them has been
only partially fixed (and introduced a new one in the W7 32 bit), the
other one hasn't been fixed at all in RTM.
>>>
>>>Thanks for the insight and background information.  I'll probably wait
>>>until 1.7 is out of beta and an "official" migration document is
>>>released.
>>
>>What "official" migration document?  There will be a release
>>announcment and that's it.
>
>Something like "how to move from 1.5 to 1.7".  Or will it be an
>automatic process done via (and by) Setup.exe?  Or will we have to do a
>"fresh install" :-/ ?

i.e., the release announcement.

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: Can't execute scripts from a samba share with 1.7

[Jon TURNEY]

On 06/08/2009 18:50, Nahor wrote:

Corinna Vinschen wrote:

On Aug 5 13:40, Nahor wrote:

If I mount with "noacl", I get a slightly different error but still
no cigar:
$ ./t.sh
-bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
$

This only happens if your account doesn't have execute permissions for
the interpreter, in this case /bin/sh. Is it possible that /bin/sh.exe
has weird permission settings for some reason?


The permissions on the interpreter are OK.
$ ls -l /bin/sh
-rwxr-xr-x 1 nahor Administrators 472064 Jul 1 18:20 /bin/sh
$

For that matter, scripts running off the local disk run fine.

Looks like the same problem of inconsistent account ID, setting the
permissions to 755 or running as the domain user fix the "bad
interpreter" error.


I also have this problem in it's second (noacl) form.  With this mount

//necker/jon on /home/jon type smbfs (binary,exec,noacl,user)

running the t.sh test script fails in a directory on this mount

j...@byron ~
$ ls -al t.sh
-rwxr-xr-x 1 Jon None 19 2009-08-06 15:46 t.sh

j...@byron ~
$ ./t.sh
-bash: ./t.sh: /bin/sh: bad interpreter: Permission denied

but works fine in a different directory

j...@byron ~
$ cp t.sh /

j...@byron ~
$ cd /

j...@byron /
$ ./t.sh
foo

Running .exe's from the share works fine.

I don't think I have the option of not using noacl, since this share resides 
on a LinkStation NAS which is running an old version of Samba (2.2.2 if google 
is to be believed) without acl support.


I'm pretty sure this used to work with Cygwin 1.5

>> One weird thing though, the directory permission are 700 and yet I can
>> list the content of the directory, cd in it and add/delete files. So
>> permissions are not consistently checked. But then, I assume it's
>> because all that is done by Windows/Samba while the permission check on
>> the script is done by Cygwin? Same thing with executing binary (I was
>> able to execute a binary file copied on the share even though I couldn't
>> execute scripts)?
>
> Most of Cygwin relys on the permission checks of the underlying OS.
> In case of scripts, that's not possible.  Therefore it has to check
> script permissions explicitely.  Note that it doesn't do a simple
> POSIX permission bit check, rather it calls an OS function asking
> "does *this* account have the right to execute *that* file?"  That
> should result in the most consistent behaviour, as far as Windows
> consistency goes.

Forgive me if you've already explained the solution, but how then do I arrange 
for scripts on this share to be seen as executable?


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

Perl bug (was Re: [1.7] cygwin allows writing to readonly files)

[Corinna Vinschen]

On Aug 10 20:11, Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
> Vinschen wrote:
> > That's a bug in your testsuite.  I assume you're running the tests as
> > administrator, right?  Administrators have the right to write to all
> > files, even R/O files, according to POSIX rules.  Your test would fail
> > on Linux as well, if you're running it as root.
> 
> Well, it's not my testsuite, but yes, I'm running under administrator
> account. But it makes me wonder, how does it work? Do you change ACLs
> temporarily?

No.  It's a "user privileges" thingy.  See
http://msdn.microsoft.com/en-us/library/aa379306%28VS.85%29.aspx

The SE_BACKUP_NAME and SE_RESTORE_NAME privileges are in the
administrator's user token, but they are not enabled by default.  Cygwin
just enables them at startup time, if they are available in the user
token.  Therefore, a Cygwin process has the usual POSIX-like permissions
for admin users.  It's no magic which isn't available to any other
native Win32 application.

> Anyway, it means there is a bug in perl, because on Linux:
> 
> r...@kitsu:~# touch test.txt
> r...@kitsu:~# chmod 0444 test.txt
> r...@kitsu:~# perl -e 'print "writable\n" if -w "test.txt"'
> writable
> 
> On Cygwin 1.7 perl thinks that the file is not writable.

Indeed.  Checking with strace I found that the test is the same on Linux
and Cygwin.  In both cases perl uses stat(), and the returned permissions
are the same (0444).  Further experimenting shows that perl has a
hardcoded uid == 0 test which must obviously fail on Cygwin.  If I change
the user's uid to 0, the string "writable" is printed by the above command.

That's a bug in perl.  There are other OSes out there which have
root-like permissions for non-0 uids.  Perl should use the access()
function to check for read/write/execute permissions, which always
returns the correct result independent of the uid of the current user.


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: Cron jobs visible

[Thorsten Kampe]

* Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
> On Aug 10 14:15, Thorsten Kampe wrote:
> > * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > > On Aug 10 12:57, Thorsten Kampe wrote:
> > > > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > > > the new forked cron process is visible in a console window. I
> > > > suspect that this might be related to the new "Console Window Host"
> > > > (conhost.exe) as I also get this window when I run screen inside a
> > > > shell.
> > > 
> > > Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.  Use
> > > Cygwin 1.7 instead.  It contains workarounds for a few really incredible
> > > bugs introduced in Windows 7 in terms of console windows.  I reported two 
> > > of them in the beta testing phase.  One of them has been only partially
> > > fixed (and introduced a new one in the W7 32 bit), the other one hasn't
> > > been fixed at all in RTM.
> > 
> > Thanks for the insight and background information. I'll probably wait 
> > until 1.7 is out of beta and an "official" migration document is 
> > released.
> 
> What "official" migration document?  There will be a release announcment
> and that's it.

Something like "how to move from 1.5 to 1.7". Or will it be an automatic 
process done via (and by) Setup.exe? Or will we have to do a "fresh 
install" :-/ ?

Thorsten


--
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 rebaseall not working

[Dave Korn]

cormoran wrote:
> Hello, I'm having trouble with dll remaping and I've tried to run rebaseall
> but when I issue the command I get the following error message: 
> gzip: stdin: unexpected end of file
> Does anyone know how this can be fixed?

  Argh.  You must have had a crash sometime while running setup.exe and it has
now left a corrupt file in /etc/setup.  Try running this command in a bash 
shell:

for x in /etc/setup/*.lst.gz ; do zcat $x >/dev/null || echo $x is bad ; done

  That'll tell you which package listing files have a problem.  Your easiest fix
would then be to use setup.exe to reinstall those packages, which should
regenerate a valid lst.gz file that rebaseall can then read successfully next
time you try.

cheers,
  DaveK


--
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] cygwin allows writing to readonly files

[Alexey Borzenkov]

On Mon, Aug 10, 2009 at 5:25 PM, Corinna
Vinschen wrote:
> That's a bug in your testsuite.  I assume you're running the tests as
> administrator, right?  Administrators have the right to write to all
> files, even R/O files, according to POSIX rules.  Your test would fail
> on Linux as well, if you're running it as root.

Well, it's not my testsuite, but yes, I'm running under administrator
account. But it makes me wonder, how does it work? Do you change ACLs
temporarily?

Anyway, it means there is a bug in perl, because on Linux:

r...@kitsu:~# touch test.txt
r...@kitsu:~# chmod 0444 test.txt
r...@kitsu:~# perl -e 'print "writable\n" if -w "test.txt"'
writable

On Cygwin 1.7 perl thinks that the file is not writable.

--
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: tar deletes .exe files on extraction

[Jeremy Bopp]

Corinna Vinschen wrote:
> On Aug 10 16:24, Steven Hartland wrote:
>> It might be a silly idea but would it potentially be an option to alter
>> this behaviour based on an cygwin environment variable, so that the past
>> behaviour is restored for wider compatibility.
> 
> Sorry, but no.  The switch existed in 1.5.25 (CYGWIN=transparent_exe)
> but has been explicitely removed in 1.7.

Not that I'm volunteering for the duty or anything ;-), but do you think
you would accept a patch which allows this feature to be toggled using a
mount option instead?  Assuming it's even possible, this sort of
behavior would allow someone in Steven's position to dynamically enable
the feature as necessary by creating a temporary mount of the target
directory tree prior to performing the extraction.  I can imagine
various kinds of Windows automation that could conceivably make use of
this feature, but I admit that the user base for it might be pretty small.

-Jeremy

--
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: tar deletes .exe files on extraction

[Corinna Vinschen]

On Aug 10 16:24, Steven Hartland wrote:
> In this example the result was nothing worked as the myexe is a none native
> binary only myexe.exe is a windows exe, but I wouldnt be surprised if there
> are cases where you have and exe and a data file with the name the same
> just the app with the .exe with the extension.

But it will definitely not be part of Cygwin and it shouldn't happen
in a Cygwin environment.

> It might be a silly idea but would it potentially be an option to alter
> this behaviour based on an cygwin environment variable, so that the past
> behaviour is restored for wider compatibility.

Sorry, but no.  The switch existed in 1.5.25 (CYGWIN=transparent_exe)
but has been explicitely removed in 1.7.


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: tar deletes .exe files on extraction

[Steven Hartland]

- Original Message - 
From: "Corinna Vinschen"

On Aug  8 03:16, Steven Hartland wrote:

If you extract a tar.gz file with an executable file and
an excitable file of the same name but with the .exe extension
on extract the .exe file is inexplicably deleted.

e.g.
tar -xvzf test.tar.gz
mydir/myexe.exe
mydir/myexe

ls myddir
myexe


Yeah, that's to be expected.

Cygwin always handled the .exe suffix transparently in terms of stat(2)
calls, but Cygwin 1.7 also handles them transparently in terms of
open(2) and any other call.  Therefore, if a file foo.exe exists, and an
application calls stat("foo"), it will get told that, yes, "foo" exists.
That's a basic component of being able to call foo.exe from bash by just
typing foo.  POSIX systems just don't have the .exe suffix for
executables.

AFAICS from the strace, tar unpacks mydir/myexe.exe, then it goes ahead
to unpack mydir/myexe.  It tries to open the file with O_CREAT | O_EXCL
flags.  Since the file exists from Cygwin's POV, open(2) returns -1 with
errno set to EEXIST.  If that happens tar calls unlink("mydir/myexe")
and the unlink() call succeeds, since, as mentioned above, the .exe
suffix is transparent to every filesystem call.  Therefore,
unlink("mydir/myexe") actually deletes "mydir/myexe.exe".  Then tar
proceeds to unpack "mydir/myexe".

Keep in mind that myexe and myexe.exe are for all practical purposes the
same file from Cygwin's point of view.  On a POSIX system you just don't
have a "normal" file called myexe in the same directory as an executable
"myexe", since that is the same file anyway, and the .exe suffix is just
an annoying Windowism.  On Cygwin, you should avoid having a file "foo"
and a file "foo.exe" in the same directory at all cost to avoid
puzzeling POSIX borderline behaviour like this.  What you do is
essentially in the "not supported" class of problems.

Fortunately for you there's a workaround.  If the order of the files in
the tar archive is reversed, both files are unpacked.  Or, unpack
mydir/myexe.exe explicitely afterwards.  The reason that this works is
that Cygwin does not check for a file "foo", if the name of the file is
explicitely given as "foo.exe".


Thanks for the confirmation there Corinna however I do think this is quite
an issue and it likely catch people out.

In this example the result was nothing worked as the myexe is a none native
binary only myexe.exe is a windows exe, but I wouldnt be surprised if there
are cases where you have and exe and a data file with the name the same
just the app with the .exe with the extension.

It might be a silly idea but would it potentially be an option to alter
this behaviour based on an cygwin environment variable, so that the past
behaviour is restored for wider compatibility.

   Regards
   Steve


--
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.0-56: Subversion svn+ssh:// URLs often fail

[Corinna Vinschen]

On Aug 10 13:23, Robert Bogomip wrote:
> This works under 1.5 (though I seem to remember that, many moons ago, it 
> used to fail in the same way there too). Consider:
>
> $ while svn ls svn+ssh://myserver/myrepo/ >/dev/null; do date; done
> Mon Aug 10 12:57:09 GMTDT 2009
> Mon Aug 10 12:57:10 GMTDT 2009
> Mon Aug 10 12:57:11 GMTDT 2009
> Mon Aug 10 12:57:11 GMTDT 2009
> Mon Aug 10 12:57:12 GMTDT 2009
> Mon Aug 10 12:57:13 GMTDT 2009
> Mon Aug 10 12:57:14 GMTDT 2009
> Mon Aug 10 12:57:14 GMTDT 2009
> Mon Aug 10 12:57:15 GMTDT 2009
> Mon Aug 10 12:57:16 GMTDT 2009
>   7 [main] svn 2560 fork: child -1 - died waiting for longjmp before 
> initialization, retry 0, exit code 0xC005, errno 11
>   7 [main] svn 2560 fork: child -1 - died waiting for longjmp before 
> initialization, retry 0, exit code 0xC005, errno 11
> svn: Can't create tunnel: Resource temporarily unavailable
>
>
> Sometimes it fails with ?svn: Network connection closed unexpectedly.?
>
> myserver is an Ubuntu box. Cygwin ssh to myserver seems uneventful in all 
> other ways (i.e., it just works as expected). The cygwin host is Vista 
> (cygcheck output dutifully attached).

I ran this testcase on a Windows 7 RTM box, using the latest Cygwin from
CVS, in a debug and in an optimized version.  The loop ran ~2000
iterations under the debug Cygwin DLL and more then 3000 iterations
under the optimized DLL without any problem, until I killed them using
Ctrl-C.

So, either there's a BLODA problem on your machine, or the problem
has been fixed in CVS.


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: Cron jobs visible

[Corinna Vinschen]

On Aug 10 14:15, Thorsten Kampe wrote:
> * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > On Aug 10 12:57, Thorsten Kampe wrote:
> > > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > > the new forked cron process is visible in a console window. I
> > > suspect that this might be related to the new "Console Window Host"
> > > (conhost.exe) as I also get this window when I run screen inside a
> > > shell.
> > 
> > Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.  Use
> > Cygwin 1.7 instead.  It contains workarounds for a few really incredible
> > bugs introduced in Windows 7 in terms of console windows.  I reported two 
> > of them in the beta testing phase.  One of them has been only partially
> > fixed (and introduced a new one in the W7 32 bit), the other one hasn't
> > been fixed at all in RTM.
> 
> Thanks for the insight and background information. I'll probably wait 
> until 1.7 is out of beta and an "official" migration document is 
> released.

What "official" migration document?  There will be a release announcment
and that's it.  Since the test phase for Cygwin 1.7 is already more than
6 months, almost everybody should know by now what's coming.


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: Cron jobs visible

[Thorsten Kampe]

* Thorsten Kampe (Mon, 10 Aug 2009 16:28:30 +0200)
> The current version is "RTM" - "Released to manufacturing" since last 
> Thursday.

Actually it's RTM for a month now. Available on Technet and MSDN since 
last Thursday.

Thorsten


--
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: Cron jobs visible

[Mark J. Reed]

On Mon, Aug 10, 2009 at 10:28 AM, Thorsten Kampe wrote:
> The current version is "RTM" - "Released to manufacturing" since last
> Thursday.

Ah, missed that milestone.  I retract the observation then.


-- 
Mark J. Reed 

--
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: Cron jobs visible

[Thorsten Kampe]

* Mark J. Reed (Mon, 10 Aug 2009 09:35:06 -0400)
> On Mon, Aug 10, 2009 at 9:29 AM, Thorsten Kampe wrote:
> > Only if you assume that Windows 7 is still in beta (which it is not).
> 
> It won't be released until October.

Make that "it won't be available in the shops until October".

> The current version is a "release candidate".

The current version is "RTM" - "Released to manufacturing" since last 
Thursday.

> How is that different from being in beta?

Feature dreeze for instance.

> Regardless of terminology, both Windows 7 and Cygwin 1.7 are stable
> but as yet unreleased pieces of software.

Cygwin 1.7 maybe - Windows 7 definitely not.

Thorsten


--
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: emacs shell: Can't exec program: /usr/bin/bash

[Marc Girod]

Ken Brown-6 wrote:
> 
> Have you tried the latest snapshot (2009-08-04)? 
> 

Not yet, but now I downloaded it...
In fact, I'll try it only if things become unbearable,
or if my X crashes.
I tend to keep my things up for a few days...
It takes some time to set everything up.

Thanks,
Marc
-- 
View this message in context: 
http://www.nabble.com/emacs-shell%3A-Can%27t-exec-program%3A--usr-bin-bash-tp24899718p24900524.html
Sent from the Cygwin list mailing list archive at Nabble.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

cygwin rebaseall not working

[cormoran]

Hello, I'm having trouble with dll remaping and I've tried to run rebaseall
but when I issue the command I get the following error message: 
gzip: stdin: unexpected end of file
Does anyone know how this can be fixed?
-- 
View this message in context: 
http://www.nabble.com/cygwin-rebaseall-not-working-tp24900452p24900452.html
Sent from the Cygwin list mailing list archive at Nabble.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: emacs shell: Can't exec program: /usr/bin/bash

[Ken Brown]

On 8/10/2009 9:25 AM, Marc Girod wrote:

Hello,

I upgraded to 1.7.0-56, then did my usual rebaseall/peflagsall.
It went well, but now, I keep getting failures to start new shells
under GNU emacs.
I get the following error:

Can't exec program: /usr/bin/bash

Process shell<4> exited abnormally with code 127


It succeeded first a few times (I have currently 4 shells running),
and I cannot get an error starting bash from the command line.


Have you tried the latest snapshot (2009-08-04)?  It works OK for me 
under XP SP3.  I started 12 shells without a problem.


Ken

--
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: Cron jobs visible

[Mark J. Reed]

On Mon, Aug 10, 2009 at 9:29 AM, Thorsten Kampe wrote:
> Only if you assume that Windows 7 is still in beta (which it is not).

It won't be released until October.  The current version is a "release
candidate".  How is that different from being in beta?  Regardless of
terminology, both Windows 7 and Cygwin 1.7 are stable but as yet
unreleased pieces of software.

-- 
Mark J. Reed 

--
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: Cron jobs visible

[Thorsten Kampe]

* Mark J. Reed (Mon, 10 Aug 2009 08:46:11 -0400)
> n Mon, Aug 10, 2009 at 8:15 AM, Thorsten Kampe wrote:
> >> > I upgraded to Windows 7 ...
> 
> > I'll probably wait until 1.7 is out of beta and an "official" migration 
> > document is
> > released.
> 
> OK, but why are you willing to upgrade to Windows 7 while *it's* still
> in beta but reluctant to upgrade to the beta version of Cygwin that's
> supported on it? That seems a bit odd.

Only if you assume that Windows 7 is still in beta (which it is not).

Thorsten


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

emacs shell: Can't exec program: /usr/bin/bash

[Marc Girod]

Hello,

I upgraded to 1.7.0-56, then did my usual rebaseall/peflagsall.
It went well, but now, I keep getting failures to start new shells
under GNU emacs.
I get the following error:

Can't exec program: /usr/bin/bash

Process shell<4> exited abnormally with code 127


It succeeded first a few times (I have currently 4 shells running),
and I cannot get an error starting bash from the command line.

So, I'm a bit puzzled...

bash   3.2.49-23   OK
cygwin 1.7.0-56OK
emacs  23.1-10 OK
emacs-el   23.1-10 Incomplete
emacs-X11  23.1-10 OK
...

Prior to the upgrade, I had 53, and no such symptom.

Thanks,
Marc
-- 
View this message in context: 
http://www.nabble.com/emacs-shell%3A-Can%27t-exec-program%3A--usr-bin-bash-tp24899718p24899718.html
Sent from the Cygwin list mailing list archive at Nabble.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: [1.7] cygwin allows writing to readonly files

[Corinna Vinschen]

On Aug 10 17:19, Alexey Borzenkov wrote:
> Hi,
> 
> $ echo foo >test.txt
> $ chmod 0444 test.txt
> $ echo bar >test.txt
> 
> This succeeds, even though the file is readonly, and permissions don't
> allow writing to the file. What's even stranger is that other programs
> (i.e. Notepad and other editors) can't write to this file, because
> there are no writing permissions on the file. How does cygwin 1.7
> manages to bypass NT permissions in this case?
> 
> Currently this breaks ExtUtils::MakeMaker, because it expects readonly
> files not to be writable and test fails.

That's a bug in your testsuite.  I assume you're running the tests as
administrator, right?  Administrators have the right to write to all
files, even R/O files, according to POSIX rules.  Your test would fail
on Linux as well, if you're running it as root.


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

[1.7] cygwin allows writing to readonly files

[Alexey Borzenkov]

Hi,

$ echo foo >test.txt
$ chmod 0444 test.txt
$ echo bar >test.txt

This succeeds, even though the file is readonly, and permissions don't
allow writing to the file. What's even stranger is that other programs
(i.e. Notepad and other editors) can't write to this file, because
there are no writing permissions on the file. How does cygwin 1.7
manages to bypass NT permissions in this case?

Currently this breaks ExtUtils::MakeMaker, because it expects readonly
files not to be writable and test fails.

--
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: tar deletes .exe files on extraction

[Corinna Vinschen]

On Aug  8 03:16, Steven Hartland wrote:
> If you extract a tar.gz file with an executable file and
> an excitable file of the same name but with the .exe extension
> on extract the .exe file is inexplicably deleted.
>
> e.g.
> tar -xvzf test.tar.gz
> mydir/myexe.exe
> mydir/myexe
>
> ls myddir
> myexe

Yeah, that's to be expected.

Cygwin always handled the .exe suffix transparently in terms of stat(2)
calls, but Cygwin 1.7 also handles them transparently in terms of
open(2) and any other call.  Therefore, if a file foo.exe exists, and an
application calls stat("foo"), it will get told that, yes, "foo" exists.
That's a basic component of being able to call foo.exe from bash by just
typing foo.  POSIX systems just don't have the .exe suffix for
executables.

AFAICS from the strace, tar unpacks mydir/myexe.exe, then it goes ahead
to unpack mydir/myexe.  It tries to open the file with O_CREAT | O_EXCL
flags.  Since the file exists from Cygwin's POV, open(2) returns -1 with
errno set to EEXIST.  If that happens tar calls unlink("mydir/myexe")
and the unlink() call succeeds, since, as mentioned above, the .exe
suffix is transparent to every filesystem call.  Therefore,
unlink("mydir/myexe") actually deletes "mydir/myexe.exe".  Then tar
proceeds to unpack "mydir/myexe".

Keep in mind that myexe and myexe.exe are for all practical purposes the
same file from Cygwin's point of view.  On a POSIX system you just don't
have a "normal" file called myexe in the same directory as an executable
"myexe", since that is the same file anyway, and the .exe suffix is just
an annoying Windowism.  On Cygwin, you should avoid having a file "foo"
and a file "foo.exe" in the same directory at all cost to avoid
puzzeling POSIX borderline behaviour like this.  What you do is
essentially in the "not supported" class of problems.

Fortunately for you there's a workaround.  If the order of the files in
the tar archive is reversed, both files are unpacked.  Or, unpack
mydir/myexe.exe explicitely afterwards.  The reason that this works is
that Cygwin does not check for a file "foo", if the name of the file is
explicitely given as "foo.exe".


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: Cron jobs visible

[Mark J. Reed]

n Mon, Aug 10, 2009 at 8:15 AM, Thorsten Kampe wrote:
>> > I upgraded to Windows 7 ...

> I'll probably wait until 1.7 is out of beta and an "official" migration 
> document is
> released.

OK, but why are you willing to upgrade to Windows 7 while *it's* still
in beta but reluctant  to upgrade to the beta version of Cygwin that's
supported on it?  That seems a bit odd.
-- 
Mark J. Reed 

--
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: simple multithread program fails on Cygwin, succeeds on Linux

[Nicholas Sherlock]

Bruno Haible wrote:

Hi,

The attached test program for pthread_once uses the following basic POSIX
threads functions:
  pthread_create
  pthread_join
  pthread_mutex_init
  pthread_mutex_lock
  pthread_mutex_unlock
  pthread_once
  pthread_rwlock_init
  pthread_rwlock_rdlock
  pthread_rwlock_unlock
  pthread_rwlock_wrlock


In Cygwin 1.5 there was a bug that meant that you could not lock a 
rwlock recursively for read (it would just deadlock on the second 
acquire). I didn't study the code for very long, but this might be the 
problem you're encountering. In any case, Cygwin 1.7 fixes at least one 
problem with rwlocks so it's a good upgrade choice.


Cheers,
Nicholas Sherlock


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

1.7.0-56: Subversion svn+ssh:// URLs often fail

[Robert Bogomip]

This works under 1.5 (though I seem to remember that, many moons 
ago, it used to fail in the same way there too). Consider:


$ while svn ls svn+ssh://myserver/myrepo/ >/dev/null; do date; done
Mon Aug 10 12:57:09 GMTDT 2009
Mon Aug 10 12:57:10 GMTDT 2009
Mon Aug 10 12:57:11 GMTDT 2009
Mon Aug 10 12:57:11 GMTDT 2009
Mon Aug 10 12:57:12 GMTDT 2009
Mon Aug 10 12:57:13 GMTDT 2009
Mon Aug 10 12:57:14 GMTDT 2009
Mon Aug 10 12:57:14 GMTDT 2009
Mon Aug 10 12:57:15 GMTDT 2009
Mon Aug 10 12:57:16 GMTDT 2009
  7 [main] svn 2560 fork: child -1 - died waiting for longjmp 
before initialization, retry 0, exit code 0xC005, errno 11
  7 [main] svn 2560 fork: child -1 - died waiting for longjmp 
before initialization, retry 0, exit code 0xC005, errno 11

svn: Can't create tunnel: Resource temporarily unavailable


Sometimes it fails with “svn: Network connection closed unexpectedly.”

myserver is an Ubuntu box. Cygwin ssh to myserver seems uneventful 
in all other ways (i.e., it just works as expected). The cygwin host 
is Vista (cygcheck output dutifully attached).


Regards,
--
Bob
Cygwin Configuration Diagnostics
Current System Time: Mon Aug 10 12:54:03 2009

Windows Vista Business Ver 6.0 Build 6002 Service Pack 2

Path:   C:\Tools\cygwin17\usr\local\bin
C:\Tools\cygwin17\bin
C:\Tools\cygwin17\bin
C:\Tools\cygwin17\usr\X11R6\bin
C:\Tools\VC8\Common7\IDE
C:\Tools\VC8\VC\BIN
C:\Tools\VC8\Common7\Tools
C:\Tools\VC8\SDK\v2.0\bin
C:\Windows\Microsoft.NET\Framework\v2.0.50727
C:\Tools\VC8\VC\VCPackages
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Tools\cygwin17\bin
C:\Tools\ntbin

Output from C:\Tools\cygwin17\bin\id.exe (nontsec)
UID: 1000(bob) GID: 513(None)
545(Users)513(None)

Output from C:\Tools\cygwin17\bin\id.exe (ntsec)
UID: 1000(bob) GID: 513(None)
545(Users)513(None)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'bob'
PWD = '/cygdrive/c/Users/bob/home'
CYGWIN = 'nontsec tty'
HOME = '/cygdrive/c/Users/bob/home'

HOMEPATH = '\Users\bob'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Users\bob\AppData\Roaming'
SSH_AGENT_PID = '4152'
HOSTNAME = 'fish'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 11, GenuineIntel'
HISTSIZE = '2000'
WINDIR = 'C:\Windows'
VS80COMNTOOLS = 'C:\Tools\VC8\Common7\Tools\'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/Users/bob/home/dir'
USERDOMAIN = 'fish'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
HISTFILESIZE = '2000'
VS90COMNTOOLS = 'C:\Tools\VC9\Common7\Tools\'
TEMP = '/cygdrive/c/Users/bob/AppData/Local/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Tools\VC8\VC\LIB;C:\Tools\VC8\VC\PlatformSDK\Lib;'
SSH_AUTH_SOCK = 'c:/Tools/cygwin/etc/agent.sock'
USERNAME = 'bob'
LIBPATH = 'C:\Windows\Microsoft.NET\Framework\v2.0.50727'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Users\bob'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\fish'
HISTIGNORE = '[   ]*:&:bg:fg:exit'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\bob\AppData\Local'
!C: = 'C:\Users\bob'
HISTCONTROL = 'ignoreboth:erasedups'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.RB;.RBW'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/cygdrive/c/Users/bob/AppData/Local/Temp'
SYSTEMROOT = 'C:\Windows'
LESS = '-sich3y3'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0f0b'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
RUBYOPT = '-rubygems'
NUMBER_OF_PROCESSORS = '4'
VIM = 'C:/Tools/Vim'
INCLUDE = 'C:\Tools\VC8\VC\INCLUDE;C:\Tools\VC8\VC\PlatformSDK\Include;'
SESSIONNAME = 'Console'
!ExitCode = ''
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Console\C:_Tools_cygwin_bin_bash.exe
  (default) = 0x0001
  WindowPosition = 0x00180175
  FontSize = 0x0014000a
  FontFamily = 0x0030
  FontWeight = 0x0190
  FaceName = ''
  HistoryNoDup = 0x0001
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
 Menu\Programs\Cygwin
  (default) = (unsupported type)
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
 Menu\Programs\Cygwin-X
  (default) = (unsupported type)
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus 
Solutions\Cygwin
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus 
Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x002

Re: Cron jobs visible

[Thorsten Kampe]

* Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> On Aug 10 12:57, Thorsten Kampe wrote:
> > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > the new forked cron process is visible in a console window. I
> > suspect that this might be related to the new "Console Window Host"
> > (conhost.exe) as I also get this window when I run screen inside a
> > shell.
> 
> Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.  Use
> Cygwin 1.7 instead.  It contains workarounds for a few really incredible
> bugs introduced in Windows 7 in terms of console windows.  I reported two 
> of them in the beta testing phase.  One of them has been only partially
> fixed (and introduced a new one in the W7 32 bit), the other one hasn't
> been fixed at all in RTM.

Thanks for the insight and background information. I'll probably wait 
until 1.7 is out of beta and an "official" migration document is 
released. But maybe the annoyance factor becomes too high and I'll do 
that even sooner.

Thanks again, Thorsten


--
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: Cron jobs visible

[Corinna Vinschen]

On Aug 10 12:57, Thorsten Kampe wrote:
> Hi,
> 
> I upgraded to Windows 7 on Sunday and now whenever cron runs a job, the 
> new forked cron process is visible in a console window. I suspect that 
> this might be related to the new "Console Window Host" (conhost.exe) as 
> I also get this window when I run screen inside a shell.

Cygwin 1.5.25, I presume.  Cygwin 1.5.25 is not supported under W7.  Use
Cygwin 1.7 instead.  It contains workarounds for a few really incredible
bugs introduced in Windows 7 in terms of console windows.  I reported two 
of them in the beta testing phase.  One of them has been only partially
fixed (and introduced a new one in the W7 32 bit), the other one hasn't
been fixed at all in RTM.


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: simple multithread program fails on Cygwin, succeeds on Linux

[Corinna Vinschen]

On Aug 10 12:13, Bruno Haible wrote:
> Hi,
> 
> The attached test program for pthread_once uses the following basic POSIX
> threads functions:
>   pthread_create
>   pthread_join
>   pthread_mutex_init
>   pthread_mutex_lock
>   pthread_mutex_unlock
>   pthread_once
>   pthread_rwlock_init
>   pthread_rwlock_rdlock
>   pthread_rwlock_unlock
>   pthread_rwlock_wrlock
> 
> On Linux with glibc 2.8:
>   $ gcc bug.c -O -Wall -lpthread -o bug
>   $ ./bug
>   Starting test_once ... OK
> The test completes in about 4 seconds.
> 
> On Cygwin 1.5.25(0.156/4/2):
>   $ gcc bug.c -O -Wall -o bug.exe 
>   $ ./bug.exe
>   Starting test_once ...
> Either it does not terminates (still running after half an hour, eating
> 100% CPU time on one of the two CPUs), or it crashes rather quickly:
>   $ ./bug.exe
>   Starting test_once ...Segmentation fault (core dumped)

WJFFM under Cygwin 1.7.


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: Bad system call when calling msgsnd

[Corinna Vinschen]

On Aug 10 15:20, Huang Bambo wrote:
> Run "net star cygserver" first

Actually you have to install the service first, using the cygserver-config
script, or you can just run /usr/sbin/cygserver under your own account
for testing.  Note that under Cygwin 1.5.x you still have to use the
CYGWIN=server option when starting the client application.

See /usr/share/doc/Cygwin/cygserver.README.


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

Cron jobs visible

[Thorsten Kampe]

Hi,

I upgraded to Windows 7 on Sunday and now whenever cron runs a job, the 
new forked cron process is visible in a console window. I suspect that 
this might be related to the new "Console Window Host" (conhost.exe) as 
I also get this window when I run screen inside a shell.

Thorsten


--
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-1.7/clisp-2.48-1: Cannot initialize clisp with full linking set

[Reini Urban]

2009/8/9 Mark Harig:
> Thank you for providing clisp version 2.48.
>
> I am unable to start clisp if I specify the full linking set:
>
> $ clisp -Kfull
> /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries:
> svm.dll: cannot open shared object file: No such file or directory
>
> $ cygcheck -l clisp | grep svm.dll
> /usr/lib/clisp-2.48/full/svm.dll
>
> $ file /usr/lib/clisp-2.48/full/svm.dll
> /usr/lib/clisp-2.48/full/svm.dll: PE32 executable for MS Windows (DLL)
> (console) Intel 80386 32-bit
>
> $ md5sum /usr/lib/clisp-2.48/full/svm.dll
> 3f0dfd94d955bfb567581c853ed32587 */usr/lib/clisp-2.48/full/svm.dll
>
> $ cygcheck -c clisp
> Cygwin Package Information
> Package              Version        Status
> clisp                2.48-1         OK
>
>
> /usr/lib/clisp-2.48/full/svm.dll was installed with the executable
> permission turned off.

oops.

> Turning on the executable permission had no effect:
> $ chmod +x /usr/lib/clisp-2.48/full/svm.dll

For me it works after
  chmod +x /usr/lib/clisp-2.48/full/svm.dll
because I have installed cygdb-4.6.dll

$ clisp -K full -norc

$ cygcheck /lib/clisp-2.48/full/lisp.exe

> $ ls -l /usr/lib/clisp-2.48/full/svm.dll
> -rwxr-xr-x 1 username root 99K Aug  1 16:02
> /usr/lib/clisp-2.48/full/svm.dll*
>
> $ clisp -Kfull
> /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries:
> svm.dll: cannot open shared object file: No such file or directory
>
> Also, the following (possibly related?) problem exists:
>
> $ cd /usr/lib/clisp-2.48/full
> $ clisp -Kfull
> /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries:
> cygdb-4.6.dll: cannot open shared object file: No such file or directory
>
>
> There is no version cygdb-4.6.dll installed, and, as far as I can tell,
> there is no version cygdb-4.6.dll available yet.

> Can anyone suggest any troubleshooting steps to take to resolve this
> problem,
> or are these problems above caused by errors in the Cygwin packaging of
> clisp?

These are packaging errors, sorry, and I can reproduce it.

I'll roll a -2 ASAP, but I want to test the new libsigsegv-2.7 also,
as it was reported to fail.

In the meantime you can fix it by:

1) chmod +x /lib/clisp-2.48/full/svm.dll; cp /lib/clisp-2.48/full/svm.dll /bin
2) The missing libdb4.6 you can get by adding the
ftp://sourceware.org/pub/cygwinports
   url to your setup and just adding libdb4.6
-- 
Reini Urban
http://phpwiki.org/   http://murbreak.at/

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

simple multithread program fails on Cygwin, succeeds on Linux

[Bruno Haible]

Hi,

The attached test program for pthread_once uses the following basic POSIX
threads functions:
  pthread_create
  pthread_join
  pthread_mutex_init
  pthread_mutex_lock
  pthread_mutex_unlock
  pthread_once
  pthread_rwlock_init
  pthread_rwlock_rdlock
  pthread_rwlock_unlock
  pthread_rwlock_wrlock

On Linux with glibc 2.8:
  $ gcc bug.c -O -Wall -lpthread -o bug
  $ ./bug
  Starting test_once ... OK
The test completes in about 4 seconds.

On Cygwin 1.5.25(0.156/4/2):
  $ gcc bug.c -O -Wall -o bug.exe 
  $ ./bug.exe
  Starting test_once ...
Either it does not terminates (still running after half an hour, eating
100% CPU time on one of the two CPUs), or it crashes rather quickly:
  $ ./bug.exe
  Starting test_once ...Segmentation fault (core dumped)

This is on a machine with 2 virtual processors:

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
type: primary processor
cpu family  : 6
model   : 12
model name  : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
stepping: 2
brand id: 0
cpu count   : 2
apic id : 0
cpu MHz : 1600
fpu : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clfl dtes acpi mmx fxsr sse sse2 ss htt tmi pbe pni monitor ds_cpl tm2 est
processor   : 1
vendor_id   : GenuineIntel
type: primary processor
cpu family  : 6
model   : 12
model name  : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
stepping: 2
brand id: 0
cpu count   : 2
apic id : 1
cpu MHz : 1599
fpu : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clfl dtes acpi mmx fxsr sse sse2 ss htt tmi pbe pni monitor ds_cpl tm2 est

You can see what the program is doing before it crahes or while it loops,
by setting   #define ENABLE_DEBUGGING 1  in line 25.

I have other test programs which exercise pthread_mutex_*, pthread_rwlock_*,
and pthread_join. These work fine. My suspicion therefore lies on pthread_once.

Bruno



/* Enable GNU extensions on systems that have them.  */
#ifndef _GNU_SOURCE
# define _GNU_SOURCE 1
#endif
/* Enable threading extensions on Solaris.  */
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1
#endif
/* Enable general extensions on Solaris.  */
#ifndef __EXTENSIONS__
# define __EXTENSIONS__ 1
#endif

/* Whether to enable locking.
   Uncomment this to get a test program without locking, to verify that
   it crashes.  */
#define ENABLE_LOCKING 1

/* Whether to help the scheduler through explicit yield().
   Uncomment this to see if the operating system has a fair scheduler.  */
#define EXPLICIT_YIELD 1

/* Whether to print debugging messages.  */
#define ENABLE_DEBUGGING 0

/* Number of simultaneous threads.  */
#define THREAD_COUNT 10

/* Number of operations performed in each thread.
   This is quite high, because with a smaller count, say 5000, we often get
   an "OK" result even without ENABLE_LOCKING (on Linux/x86).  */
#define REPEAT_COUNT 5

#include 
#include 
#include 

#include 
#include 

/* Use the POSIX threads library.  */
# include 

#if ENABLE_DEBUGGING
# define dbgprintf printf
#else
# define dbgprintf if (0) printf
#endif

# include 
# include 
#if EXPLICIT_YIELD
# define yield() sched_yield ()
#else
# define yield()
#endif

/* Test once-only execution by having several threads attempt to grab a
   once-only task simultaneously (triggered by releasing a read-write lock).  */

static pthread_once_t fresh_once = PTHREAD_ONCE_INIT;
static int ready[THREAD_COUNT];
static pthread_mutex_t ready_lock[THREAD_COUNT];
#if ENABLE_LOCKING
static pthread_rwlock_t fire_signal[REPEAT_COUNT];
#else
static volatile int fire_signal_state;
#endif
static pthread_once_t once_control;
static int performed;
static pthread_mutex_t performed_lock = PTHREAD_MUTEX_INITIALIZER;

static void
once_execute (void)
{
  if (pthread_mutex_lock (&performed_lock))
abort ();
  performed++;
  if (pthread_mutex_unlock (&performed_lock))
abort ();
}

static void *
once_contender_thread (void *arg)
{
  int id = (int) (long) arg;
  int repeat;

  for (repeat = 0; repeat <= REPEAT_COUNT; repeat++)
{
  /* Tell the main thread that we're ready.  */
  if (pthread_mutex_lock (&ready_lock[id]))
abort ();
  ready[id] = 1;
  if (pthread_mutex_unlock (&ready_lock[id]))
abort ();

  if (repeat == REPEAT_COUNT)
	break;

  dbgprintf ("Contender %p waiting for signal for round %d\n",
		 (void *) pthread_self (), repeat);
#if ENABLE_LOCKING
  /* Wait for the signal to go.  */
  if (pthread_rwlock_rdlock (&fire_signal[repeat]))
abort ();
  /* And don't hinder the others (if the scheduler is unfair).  */
  if (pthread_rwlock_unlock (&fire_signal[repeat]))
abort ();
#else
  /* Wait for the signal to go.  */
  while (fire_signal_state <= repeat)
	yield ();
#endif
  dbgprintf ("Contender

Re: Bad system call when calling msgsnd

[Huang Bambo]

Run "net star cygserver" first

2009/8/10 Scott 
>
> When I compile and run the following example code within cygwin (gcc msgsnd.c 
> -o msgsnd), I get an error "Bad system call"
>
> This seems to be a bug; it runs fine under linux.
>
> #include 
>
> int main() {
>   int msqid = 0;
>   int rc;
>   size_t msgsz;
>   struct {
>        long int mtype;
>       char     mtext[256];
>   } mymsg;
>
>   msgsz = 256;
>   mymsg.mtype = 1;
>   rc = msgsnd(msqid, &mymsg, msgsz,  IPC_NOWAIT);
>   return 0;
> }
>
>
> --
> 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

Bad system call when calling msgsnd

[Scott]

When I compile and run the following example code within cygwin (gcc 
msgsnd.c -o msgsnd), I get an error "Bad system call"


This seems to be a bug; it runs fine under linux.

#include 

int main() {
   int msqid = 0;
   int rc;
   size_t msgsz;
   struct {
long int mtype;
   char mtext[256];
   } mymsg;

   msgsz = 256;
   mymsg.mtype = 1;
   rc = msgsnd(msqid, &mymsg, msgsz,  IPC_NOWAIT);
   return 0;
}


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