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

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

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> 

[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

[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

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

[PATCH] Export memrchr

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

Yaakov

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

[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

[PATCH] Mouse reporting modes 1006 and 1015 for extended coordinates

This patch implements mouse modes 1006 and 1015 for the cygwin console 
(no experimental add-ons this time :) ).
They enable unlimited mouse coordinate reporting like recent xterm, 
mintty, urxvt. If someone is interested, I could also implement mouse 
mode 1005.
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
--- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
+++ ./fhandler.h	2012-04-03 15:52:07.893561600 +0200
 <at>  <at>  -1282,6 +1282,8  <at>  <at>  class dev_console

   bool insert_mode;
   int use_mouse;
+  bool ext_mouse_mode6;
+  bool ext_mouse_mode15;

console: new mouse modes, request/response attempt

This patch includes 2 things (to be fixed and separated anyway; change 
log still missing) for discussion:
* mouse modes 6 and 15 (numeric mouse coordinates)
* semi-fix for missing terminal status responses
The fix tries to detect the proper fhandler for CONIO, which is then 
used to queue the response.
Problem 1: I am not sure whether this detection is proper in all cases, 
what e.g. if /dev/tty is reopened etc. I don't know where else a 
relation between the handles for CONIN and CONOUT might be established.
Problem 2: While the response reaches the application with this patch, 
only the first byte is read right-away. Further bytes are delayed until 
other input is becoming present (typing a key). This may (or may not) be 
related to other issues with select(), so maybe it's worth analyzing it.

Thomas

diff -rup sav/fhandler.h ./fhandler.h
--- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
+++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
 <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console

   bool insert_mode;
   int use_mouse;
+  bool ext_mouse_mode6;
+  bool ext_mouse_mode15;
   bool use_focus;
   bool raw_win32_keyboard_mode;
+  fhandler_console * fh_tty;