Thomas Wolff | 16 Aug 08:33 2012
Picon

console: terminal request/response

This is another patch to enable terminal responses in the cygwin console.
Typically, terminals respond to requests to report Primary/Secondary 
Device Attributes
and to send a Cursor Position Report (see 
http://invisible-island.net/xterm/ctlseqs/ctlseqs.txt).
(This hasn't ever worked in the cygwin console except with obsolete 
setting CYGWIN=tty.)

My attached patch should now fix this. I know it's not really 
significant anymore
(http://cygwin.com/ml/cygwin-patches/2012-q2/msg00002.html) but I 
couldn't resist
to rework and fix my previous fix attempts.

Thomas
diff -rup sav/fhandler.h ./fhandler.h
--- sav/fhandler.h	2012-08-03 17:39:21.000000000 +0200
+++ ./fhandler.h	2012-08-15 16:57:09.152522000 +0200
 <at>  <at>  -1294,6 +1294,8  <at>  <at>  class dev_console
   bool ext_mouse_mode15;
   bool use_focus;
   bool raw_win32_keyboard_mode;
+  char cons_rabuf[40];
+  char * cons_rapoi;

   inline UINT get_console_cp ();
   DWORD con_to_str (char *d, int dlen, WCHAR w);
 <at>  <at>  -1384,6 +1386,7  <at>  <at>  private:
(Continue reading)

Thomas Wolff | 14 Aug 22:56 2012
Picon

/dev/clipboard pasting with small read() buffer


--- sav/fhandler_clipboard.cc	2012-07-08 02:36:47.000000000 +0200
+++ ./fhandler_clipboard.cc	2012-08-14 18:25:14.903255600 +0200
 <at>  <at>  -222,6 +222,7  <at>  <at>  fhandler_dev_clipboard::read (void *ptr,
   UINT formatlist[2];
   int format;
   LPVOID cb_data;
+  int rach;

   if (!OpenClipboard (NULL))
     {
 <at>  <at>  -243,12 +244,18  <at>  <at>  fhandler_dev_clipboard::read (void *ptr,
       cygcb_t *clipbuf = (cygcb_t *) cb_data;

       if (pos < clipbuf->len)
-      	{
+	{
 	  ret = ((len > (clipbuf->len - pos)) ? (clipbuf->len - pos) : len);
 	  memcpy (ptr, clipbuf->data + pos , ret);
 	  pos += ret;
 	}
     }
+  else if ((rach = get_readahead ()) >= 0)
+    {
+      /* Deliver from read-ahead buffer. */
+      * (char *) ptr = rach;
+      ret = 1;
+    }
(Continue reading)

Adam Dinwoodie | 3 Aug 11:07 2012

[PATCH] Make `makewhatis` FAQ entry explicitly refer to `whatis`

All,

Minor FAQ patch below to make it explicit that `makewhatis` is used for
`whatis` as well as `man -k` and `apropos`. Inspired by someone [apparently
being confused][0] on Stack Overflow (yes, they were almost certainly being
lazy, but I figure being more explicit will do no harm).

[0]: http://stackoverflow.com/questions/11774230/unix-cygwin-whatis-returns-all-commands-as-nothing-appropriate/11782300#comment15656666_11782300

I'm hoping this doesn't count as "significant" with regard to copyright
assignment. I'd really rather not have to deal with that tedium.

This is my first submitted patch; I *think* I've got everything right, but
apologies if not.

2012-08-03  Adam Dinwoodie  <Adam.Dinwoodie <at> ...>

	* faq-using.xml (faq.using.man): Make relevance to whatis explicit.

Index: faq-using.xml
===================================================================
RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v
retrieving revision 1.45
diff -u -p -r1.45 faq-using.xml
--- faq-using.xml       23 Apr 2012 22:10:37 -0000      1.45
+++ faq-using.xml       3 Aug 2012 08:55:03 -0000
 <at>  <at>  -238,7 +238,8  <at>  <at>  related messages.
 </answer></qandaentry>

 <qandaentry id="faq.using.man">
(Continue reading)

Warren Young | 31 Jul 23:01 2012

rebaseall info out of date

This paragraph in the rebase package README:

> Note that rebaseall is only a stop-gap measure.  Eventually the rebase
> functionality will be added to Cygwin's setup.exe, so that rebasing will
> happen automatically.

...should be rewritten.  I propose: "You should not need to run 
rebaseall by hand.  setup.exe has done so automatically at the end of 
each installation since Mumble 2012."  (May?  April?)

A similar thing is going on in FAQ item 4.44.  I think that FAQ item 
should be split in two, with all the rebasing related stuff answering a 
new FAQ item, "Why does Cygwin need rebasing?", refocused on talking 
about what setup.exe/rebaseall now does automatically and why.  FAQ item 
4.44 will then talk about the remaining reasons fork() can fail, and 
their possible fixes.

And while I'm proposing work for other people :) is there a better 
reason program usage info is in the README instead of man pages, besides 
lack of time or interest?  In trying to answer the question "Why do we 
need rebasing?" for myself, I first tried "man rebase".  (Yes, I did 
eventually answer the question to my satisfaction.)

Daniel Colascione | 27 Jul 10:08 2012

New modes for cygpath that terminate path with null byte, nothing

I wrote this patch because I often write this:

$ cygpath -aw foo > /dev/clipboard

Today, cygpath always appends a newline to the information in the
clipboard, which is annoying when trying to paste into a program that
interprets newlines specially. This patch implements two new options:
-0/--null and -n/--no-newline. The former separates all paths output by
cygpath with a null byte; the latter separates them with nothing at all.
With -n, my example above works more smoothly and pastes don't include a
newline.

Index: cygpath.cc
===================================================================
RCS file: /cvs/src/src/winsup/utils/cygpath.cc,v
retrieving revision 1.69
diff -u -r1.69 cygpath.cc
--- cygpath.cc	6 Jul 2012 14:52:33 -0000	1.69
+++ cygpath.cc	27 Jul 2012 08:01:19 -0000
 <at>  <at>  -37,6 +37,7  <at>  <at> 
 static char *prog_name;
 static char *file_arg, *output_arg;
 static int path_flag, unix_flag, windows_flag, absolute_flag;
+static int separator_mode; // 0 = newline, 1 = null, 2 = nothing
 static int shortname_flag, longname_flag;
 static int ignore_flag, allusers_flag, output_flag;
 static int mixed_flag, options_from_file_flag, mode_flag;
 <at>  <at>  -47,6 +48,8  <at>  <at> 
(Continue reading)

Yaakov (Cygwin/X | 11 Jun 22:58 2012
Picon
Picon

[PATCH] regex: fix for kernel cross-compile

The attached patch fixes the issue I reported previously:

http://cygwin.com/ml/cygwin/2012-06/msg00161.html

According to POSIX[1], a '|' following '(' produces undefined results. 
However, glibc and PCRE both allow the regex in question, so there is 
basis for omitting this error.  I believe this is the last issue which 
needs to be fixed within Cygwin to allow cross-compiling the Linux kernel.

Yaakov

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_03
Attachment (regex-kernel-relocs.patch): application/x-itunes-itlp, 1078 bytes
Yaakov (Cygwin/X | 5 Jun 07:08 2012
Picon
Picon

[PATCH] Add getmntent_r

This patch set implements getmntent_r, a GNU extension:

http://man7.org/linux/man-pages/man3/getmntent.3.html

libvirt needs this[1], as I just (re)discovered.  Patches for 
winsup/cygwin and winsup/doc attached.

Yaakov

[1] http://cygwin.com/ml/cygwin/2010-04/msg00885.html
Attachment (cygwin-getmntent_r.patch): application/x-itunes-itlp, 5966 bytes
Attachment (doc-getmntent_r.patch): application/x-itunes-itlp, 785 bytes
Mark Lofdahl | 25 May 20:43 2012
Picon

Re: [PATCH] Ctrl-C and non-Cygwin programs

References: <4F73CF37.4020001 <at> elfmimi.jp>

On 28/03/2012 10:55 PM, Ein Terakawa wrote:

>What it does actually is it generates CTRL_BREAK_EVENT with 
>Windows Console API GenerateConsoleCtrlEvent on the arrival of SIGINT.
>And to make this scheme to be functional it is required to specify
>CREATE_NEW_PROCESS_GROUP when creating new non-Cygwin processes.

Is there any way for me to get the old behavior? I rely heavily on the
ability to press ctrl-c in my non-cygwin console app and have that app
receive a CTRL_C_EVENT instead of a CTRL_BREAK_EVENT. Everything worked fine
for me before this patch.

>To my surprise there seem to be no way to generate CTRL_C_EVENT using API.

It is possible to generate a CTRL_C_EVENT, if you pass 0 as the process
group id, in which case the event is passed to all process that share the
console. Don't know if that would work in this situation.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155.aspx

Thanks,
Mark Lofdahl

Yaakov (Cygwin/X | 9 May 10:18 2012
Picon
Picon

[PATCH] Export memrchr

Here are the patches for exporting memrchr, once my patches to newlib
are accepted.

Yaakov

Attachment (cygwin-memrchr.patch): text/x-patch, 1926 bytes
Attachment (doc-memrchr.patch): text/x-patch, 639 bytes
Yaakov (Cygwin/X | 24 Apr 00:17 2012
Picon
Picon

Regenerate configures

cygwin/doc/configure and cygwin/testsuite/configure are now the only 
configure scripts in the winsup tree which were generated with 
autoconf-2.5x.  Any objections to regenerating them with 2.68?

Yaakov

Thomas Wolff | 22 Apr 21:07 2012
Picon

[PATCH] Extended mouse coordinates

This patch replaces my previous proposal 
(http://cygwin.com/ml/cygwin-patches/2012-q2/msg00005.html) with two 
modifications:

  * Fixed a bug that suppressed mouse reporting at large coordinates (in
    all modes actually:-\ )
  * Added mouse mode 1005 (total of 3 three new modes, so all reporting
    modes run by current terminal emulators would be implemented)

I would appreciate the patch to be applied this time, planned to be my 
last mouse patch :)

Kind regards,
Thomas
2012-04-03  Thomas Wolff  <towo <at> towo.net>

	* fhandler.h (class dev_console): Two flags for extended mouse modes.
	* fhandler_console.cc (fhandler_console::read): Implemented 
	extended mouse modes 1015 (urxvt, mintty, xterm) and 1006 (xterm).
	Not implemented extended mouse mode 1005 (xterm, mintty).
	Supporting mouse coordinates greater than 222 (each axis).
	Also: two { wrap formatting consistency fixes.
	(fhandler_console::char_command) Initialization of enhanced 
	mouse reporting modes.

diff -rup sav/fhandler.h ./fhandler.h
(Continue reading)


Gmane