Daniel Dai | 20 Jan 07:02 2014

[PATCH] Fix parameter passing containing quote/equal to Windows batch command

We notice one issue when running a Windows batch command inside
cygwin. Here is one example.

Simple batch file:
echo %1

Run it under cygwin:
./a.bat a=b

./a.bat "a=b"

If we pass additional \"
./a.bat "\"a=b\""

There seems no way to pass a=b into bat.

Attach quote.patch contains a fix. It does two things:
1. If the parameter contains a equal sign, automatically add quote
(similar to space, tab, new line, quote cygwin already do)
2. If the parameter is already quoted, don't quote again

Index: cygwin/winf.cc
RCS file: /cvs/src/src/winsup/cygwin/winf.cc,v
(Continue reading)

Christopher Faylor | 8 Jan 06:47 2014

Some of my email didn't go through in December

I changed my email configuration in December and that resulted in some
sourceware.org mailing lists not thinking I was subscribed.  So some of
my timely responses to messages here are showing up here in an untimely

I noticed this when Corinna made the same observation that I thought I
had and then realized that my messages had never shown up.



Ray Donnelly | 7 Jan 17:31 2014

Request for feedback on 3 patches I posted in December.


Could someone please look over these and give me some feedback?




Corinna Vinschen | 7 Jan 16:12 2014

Re: [PATCH] Reattach trailing dirsep on existing directories too.

On Dec 22 01:03, Ray Donnelly wrote:
> I hope this is OK and I've done it in the best place. Please advise if
> it needs any changes.

I have no idea if this is ok.  This is a patch to a very crucial
function in terms of path handling, and it's not clear that this isn't
doing the wrong thing.  What is this patch trying to accomplish?  Do you
have example user space code which is failing for this very reason?



Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
Mark Geisert | 31 Dec 06:35 2013

[PATCH] FAQ update: packages needed to build Cygwin

Hope I'm doing this correctly.  Here is the ChangeLog entry followed by 
the patch.  I wasn't sure if patch originator or patch committer, if 
different, gets their name in the ChangeLog entry.  Patch rationale 
available on request.



2013-12-31  Mark Geisert  <mark <at> maxrnd.com>

 	* faq-programming.xml: Update packages needed to build Cygwin.


Index: faq-programming.xml
RCS file: /cvs/src/src/winsup/doc/faq-programming.xml,v
retrieving revision 1.27
diff -u -r1.27 faq-programming.xml
--- faq-programming.xml 5 Jun 2013 07:57:39 -0000       1.27
+++ faq-programming.xml 31 Dec 2013 05:25:33 -0000
 <at>  <at>  -693,11 +693,19  <at>  <at> 

  <para>First, you need to make sure you have the necessary build tools
-installed; you at least need <literal>gcc</literal>, <literal>make</literal>,
-<literal>perl</literal>, and <literal>cocom</literal>. If you want to run
-the tests, <literal>dejagnu</literal> is also required.
(Continue reading)

James Johnston | 25 Dec 00:01 2013

Patch to optionally disable overlapped pipes


As I have recently mentioned on the main Cygwin mailing list, Cygwin by
default creates FILE_FLAG_OVERLAPPED named pipes for the standard file
handles (stdin/stdout/stderr).  These overlapped pipes require all programs
using ReadFile/WriteFile to use overlapped I/O when using the pipes.  Since
standard runtimes in Win32 programs don't normally use overlapped I/O on the
standard file handles, most Win32 programs will exhibit undefined behavior
when called by Cygwin.  In my case, it has resulted in a problem with
calling .NET Framework 4.0 programs from Cygwin (which, coincidentally,
NETFX 4.0 also probably has a bug resulting in undefined behavior that
definitely clashes with overlapped pipes).

The attached patch creates a new "pipe_nooverlap" flag in the CYGWIN
environment variable (similar to the existing pipe_byte flag).  By default,
the flag would not be set and Cygwin will continue to make overlapped pipes
by default, because I did not know if this will result in any breakages
elsewhere in some Cygwin packages.

If the new "pipe_nooverlap" flag is set, then Cygwin won't make overlapped
pipes by default (i.e. pipes made by the pipe or pipe2 functions).  For me,
this got NETFX 4.0 programs working again.  I've been using it all day today
with no ill effects noted.  It seems safe to use.  But I made it a flag
because I am not 100% certain that some package won't break, and it isn't
needed if you are only running Cygwin programs (which presumably use
Cygwin1.dll which presumably is using overlapped I/O everywhere).

If the maintainers feel that a CYGWIN flag isn't necessary and it is safe to
always remove FILE_FLAG_OVERLAPPED, then I can submit a patch that doesn't
have the "pipe_nooverlap" flag - i.e. just assumes the flag is always set.
(Continue reading)

Ray Donnelly | 22 Dec 02:03 2013

[PATCH] Reattach trailing dirsep on existing directories too.

I hope this is OK and I've done it in the best place. Please advise if
it needs any changes.
Ray Donnelly | 22 Dec 01:40 2013

[PATCH] Fix potentially uninitialized variable p

Ray Donnelly | 22 Dec 01:39 2013

[PATCH] Fix some debug string format specifiers.

I hope patches generated with git are OK?

Best regards,

Jon TURNEY | 13 Nov 15:37 2013

[PATCH] Prototype initstate() etc. if _XOPEN_SOURCE is defined appropriately

Not sure if this is wanted, but mesa likes to compile with '-std=c99
D_XOPEN_SOURCE=500', which leads to exciting crashes on x86_64 because
initstate() is not prototyped.

2013-11-13  Jon TURNEY  <jon.turney <at> dronecode.org.uk>

	* include/cygwin/stdlib.h(initstate, random, setstate, srandom) :
	Prototype if not __STRICT_ANSI__ or _XOPEN_SOURCE is defined appropriately.
Index: cygwin/include/cygwin/stdlib.h
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/stdlib.h,v
retrieving revision 1.13
diff -u -u -p -r1.13 stdlib.h
--- cygwin/include/cygwin/stdlib.h	21 May 2013 19:04:49 -0000	1.13
+++ cygwin/include/cygwin/stdlib.h	13 Nov 2013 14:28:35 -0000
 <at>  <at>  -31,10 +31,14  <at>  <at>  void	setprogname (const char *);
 char *realpath (const char *, char *);
 char *canonicalize_file_name (const char *);
 int unsetenv (const char *);
+#endif /*__STRICT_ANSI__*/
+#if !defined(__STRICT_ANSI__) || (_XOPEN_SOURCE >= 500) || (defined(_XOPEN_SOURCE) && defined(_XOPEN_SOURCE_EXTENDED))
 char *initstate (unsigned seed, char *state, size_t size);
 long random (void);
 char *setstate (const char *state);
 void srandom (unsigned);
+#ifndef __STRICT_ANSI__
(Continue reading)

Eric Blake | 26 Sep 01:26 2013

fix off-by-one in dup2

Solves the segfault here: http://cygwin.com/ml/cygwin/2013-09/msg00397.html
but does not address the fact that we are still screwy with regards to

Ultimately, based on my understanding of POSIX and glibc, my goal is to
have a number of changes (this patch only scratches the surface; there's
more to go):

dtable.h tracks soft and hard limits, inherited over fork and preserved
across exec

hard limit starts at OPEN_MAX_MAX and can only be reduced
soft limit starts at hard limit, and can be reduced to _POSIX_OPEN_MAX (8)
dtable.size starts at MAX(32, fork/exec size)

getdtablesize() and sysconf(_SC_OPEN_MAX) always returns the soft limit,
as in glibc and permitted by POSIX (_SC_OPEN_MAX is the only sysconf
variable that can be runtime dynamic)

dtable.size is decoupled from soft limit, and is guaranteed to be <=
hard limit.  It can grow up to current soft limit; but soft limit can
later be reduced lower than dtable.size (glibc does this); on fork and
exec, we are careful to still allow fds beyond the current soft limit.

getrlimit(RLIMIT_NOFILE, &r) => returns soft and hard limits from dtable
rather than hard limit as a constant and soft limit as current dtable.size

setrlimit(RLIMIT_NOFILE, &r) => cannot set hard limit to unlimited; soft
limit of unlimited is translated to current hard limit; hard limit
(Continue reading)