Re: [PATCH v3] Cygwin: console, pty: Prevent error in legacy console mode.

2019-11-11 Thread Takashi Yano
Hi Ken,

On Mon, 11 Nov 2019 19:39:46 +
Ken Brown wrote:
> After this commit, the XWin Server Start Menu shortcut no longer works.  I 
> think 
> it's /usr/bin/xwin-xdg-menu.exe that fails, but I haven't checked this 
> carefully.

Could you please check whether the attached patch solves the issue?

-- 
Takashi Yano 


revise-check-con-is-legacy.patch
Description: Binary data


Re: [PATCH] regtool: Ignore /proc/registry{,32,64}/ prefix, with forward or backslashes, allowing path completion

2019-11-11 Thread Brian Inglis
On 2019-11-11 09:28, Corinna Vinschen wrote:
> On Nov 11 08:30, Brian Inglis wrote:
>> On 2019-11-11 02:19, Corinna Vinschen wrote:
>>> On Nov 11 10:13, Corinna Vinschen wrote:
 On Nov 10 09:14, Brian Inglis wrote:
 The patch idea is nice.  Two nits, though.
 Please shorten the commit msg summary line and add a bit of descriptive
 text instead.
>>
>> Sorry, I forget and don't notice longer than standard messages, from using
>> 120x60 or larger windows.
>>
> ---
>  winsup/utils/regtool.cc | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
> index a44d90768..ddb1304cd 100644
> --- a/winsup/utils/regtool.cc
> +++ b/winsup/utils/regtool.cc
> @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
>"  usersHKU   HKEY_USERS\n"
>"\n"
>"If the keyname starts with a forward slash ('/'), the forward 
> slash is used\n"
> -  "as separator and the backslash can be used as escape 
> character.\n");
> +  "as separator and the backslash can be used as escape character.\n"
> +  "If the keyname starts with /proc/registry{,32,64}/, using forward 
> or backward\n"
> +  "slashes, allowing path completion, that part of the prefix is 
> ignored.\n");

 Is that really essential user information?
>>
>> Absolutely essential!
>>
 I assume this behaviour is something you just expected to work but then
 didn't.  With your patch it now works as you expected.  So it's kind of
 a bugfix, rather than a change of behaviour the user needs to learn about.
>>
>> To those with similar background or experience it may appear that it should 
>> be
>> supported, but hasn't been until now.
>>
>> It is definitely not expected behaviour, given how regedit, reg, etc. expect
>> only hive paths, and how the the current regtool --help reads, clearly 
>> expecting
>> Windows style backslash separated registry paths, probably pasted within 
>> single
>> quotes. That expectation is changed somewhat by the forward slash sentence.
>> Further changes to expectation needs more documentation.
>>
 The above text is, IMHO, more confusing than helpful to a user just
 asking for regtool --help.  I'd just drop it.
>>
>> It needs documented because it can not in any way be inferred from the 
>> existing
>> regtool ---help, and would not be expected, that it should work. It was never
>> previously supported or seen as helpful or necessary, so it should be seen 
>> as a
>> non-obvious "surprising" addition, in the opposite sense to "least surprise".
>>
>> Please someone suggest better wording for the help, as that is the only
>> documentation available, and is needed, to update existing and inform new 
>> users.
>> Like the code, I tried to maintain the style of the existing help.
>>
>> As an alternative, how about:
>> "To support path completion, a keyname prefix of /proc/registry{,32,64}/ is
>> ignored."
> 
> Ok, we can add something to the help text, but the text still sounds
> confusing, even the altenative one.  I think the reason is the negative
> expression "ignore" here.  Why not express this in a positive way like
> this:
> 
>   "Use the /proc/registry{,32,64}/ registry path prefix to utilize path
>completion."
> 
> Something like that anyway.

Maybe something may be misinterpreted from your consideration of International
English wording that is not even considered in my native English; "is ignored"
is passive voice but not negative in English, and neither does it appear to be
so in Deutsch (via Google): "Zur Unterstützung der Pfadvervollständigung wird
das Schlüsselnamenpräfix /proc/registry{,32,64}/ ignoriert."
Please advise if you can think why there is a wording issue.

I found the doc/utils.xml entry and added the improved sentence to both,
changing the example to be consistent and the better choice to exemplify the
alternative, and better fit the UG, man pages, and --help.

Please review the resubmission.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


Re: [PATCH v3] Cygwin: console, pty: Prevent error in legacy console mode.

2019-11-11 Thread Ken Brown
Hi Takashi,

On 11/6/2019 11:29 AM, Takashi Yano wrote:
> ---
>   winsup/cygwin/environ.cc  |  2 +-
>   winsup/cygwin/fhandler.h  |  1 +
>   winsup/cygwin/fhandler_console.cc | 46 ---
>   winsup/cygwin/fhandler_tty.cc | 14 ++
>   4 files changed, 46 insertions(+), 17 deletions(-)

After this commit, the XWin Server Start Menu shortcut no longer works.  I 
think 
it's /usr/bin/xwin-xdg-menu.exe that fails, but I haven't checked this 
carefully.

I'm attaching the log file, in which you can see that GetSystemMenu fails.

Ken
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18362 moufang2 3.1.0-340.x86_64 2019-11-03 14:54 UTC x86_64
OS: Windows 10  [Windows NT 10.0 build 18362] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -auth 
 /home/kbrown/.serverauth.1225 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 3840 h 2160
winInitializeScreenDefaults - native DPI x 240 y 240
[2546229.671] (II) xorg.conf is not supported
[2546229.671] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more 
information
[2546229.671] LoadPreferences: /home/kbrown/.XWinrc not found
[2546229.671] LoadPreferences: Loading /etc/X11/system.XWinrc
[2546229.671] LoadPreferences: Done parsing the configuration file...
[2546229.671] winDetectSupportedEngines - RemoteSession: no
[2546229.687] winDetectSupportedEngines - DirectDraw4 installed, allowing 
ShadowDDNL
[2546229.687] winDetectSupportedEngines - Returning, supported engines 0005
[2546229.687] winSetEngine - Multi Window or Rootless => ShadowGDI
[2546229.687] winScreenInit - Using Windows display depth of 32 bits per pixel
[2546229.703] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 
2160 depth: 32
[2546229.703] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[2546229.703] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 
8 d 24 bpp 32
[2546229.703] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[2546229.718] (II) AIGLX: Testing pixelFormatIndex 1
[2546229.734] GL_VERSION: 4.6.0 - Build 26.20.100.6952
[2546229.734] GL_VENDOR:  Intel
[2546229.734] GL_RENDERER:Intel(R) UHD Graphics 630
[2546229.734] (II) GLX: enabled GLX_SGI_make_current_read
[2546229.734] (II) GLX: enabled GLX_SGI_swap_control
[2546229.734] (II) GLX: enabled GLX_MESA_swap_control
[2546229.734] (II) GLX: enabled GLX_SGIX_pbuffer
[2546229.734] (II) GLX: enabled GLX_ARB_multisample
[2546229.734] (II) GLX: enabled GLX_SGIS_multisample
[2546229.734] (II) GLX: enabled GLX_ARB_fbconfig_float
[2546229.734] (II) GLX: enabled GLX_EXT_fbconfig_packed_float
[2546229.734] (II) GLX: enabled GLX_ARB_create_context
[2546229.734] (II) GLX: enabled GLX_ARB_create_context_profile
[2546229.734] (II) GLX: enabled GLX_ARB_create_context_robustness
[2546229.734] (II) GLX: enabled GLX_EXT_create_context_es2_profile
[2546229.734] (II) GLX: enabled GLX_ARB_framebuffer_sRGB
[2546229.734] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[2546229.734] (II) 103 pixel formats reported by wglGetPixelFormatAttribivARB
[2546229.734] (II) 67 fbConfigs
[2546229.734] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel type, 
36 unaccelerated
[2546229.734] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[2546229.875] winPointerWarpCursor - Discarding first warp: 1920 1080
[2546229.875] (--) 16 mouse buttons found
[2546229.875] (--) Setting autorepeat to delay=500, rate=31
[2546229.875] (--) Windows keyboard layout: "0409" (0409) "US", type 4
[2546229.875] (--) Found matching XKB configuration "English (USA)"
[2546229.875] (--) Model = "pc105" Layout = "us" Variant = "none" Options = 
"none"
[2546229.875] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" 
Options = "none"
[2546229.875] winInitMultiWindowWM - DISPLAY=:0.0
[2546229.875] winMultiWindowXMsgProc - DISPLAY=:0.0
[2546229.921] winMultiWindowXMsgProc - xcb_connect() returned and successfully 
opened the display.
[2546229.921] [2546229.921] winProcEstablishConnection - winInitClipboard 
returned.
winClipboardThreadProc - DISPLAY=:0.0
[2546229.921] winInitMultiWindowWM - xcb_connect () returned and successfully 
opened the display.
[2546229.921] winClipboardProc - xcb_connect () returned and successfully 
opened the display.
[2546229.937] Using Composite redirection
[2546277.843] OS has icon alpha channel support: yes
[2546460.515] SetupSysMenu: GetSystemMenu() failed for HWND 0x240af2
[2546460.531] IsOverrideRedirect: Failed to get window attributes
[2546466.031] SetupSysMenu: GetSystemMenu() failed for HWND 0x490a82
[2546554.765] SetupSysMenu: GetSystemMenu() failed for HWND 0x240f02
[2546648.828] SetupSysMenu: GetSystemMenu() failed for HWND 0x620a82
[2546653.765] SetupSysMenu: GetSystemMenu() failed for HWND 0x630a82
[2546669.203] SetupSysMenu: 

[PATCH] regtool: allow /proc/registry{,32,64}/ registry path prefix

2019-11-11 Thread Brian Inglis
The user can supply the registry path prefix /proc/registry{,32,64}/ to
use path completion.
---
 winsup/doc/utils.xml|  7 +--
 winsup/utils/regtool.cc | 17 ++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/winsup/doc/utils.xml b/winsup/doc/utils.xml
index 043ed7358..5f266bcb1 100644
--- a/winsup/doc/utils.xml
+++ b/winsup/doc/utils.xml
@@ -1976,8 +1976,11 @@ remote host in either \\hostname or hostname: format and 
prefix is any of:
   usersHKU   HKEY_USERS
 
 You can use forward slash ('/') as a separator instead of backslash, in
-that case backslash is treated as escape character
-Example: regtool get '\user\software\Microsoft\Clock\iFormat'
+that case backslash is treated as an escape character.
+You can also supply the registry path prefix /proc/registry{,32,64}/ to
+use path completion.
+Example:
+  regtool list '/HKLM/SOFTWARE/Classes/MIME/Database/Content Type/audio\\/wav'
 
 
 
diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
index a44d90768..f91e61d00 100644
--- a/winsup/utils/regtool.cc
+++ b/winsup/utils/regtool.cc
@@ -166,11 +166,13 @@ usage (FILE *where = stderr)
   "  machine  HKLM  HKEY_LOCAL_MACHINE\n"
   "  usersHKU   HKEY_USERS\n"
   "\n"
-  "If the keyname starts with a forward slash ('/'), the forward slash is 
used\n"
-  "as separator and the backslash can be used as escape character.\n");
+  "You can use forward slash ('/') as a separator instead of backslash, 
in\n"
+  "that case backslash is treated as an escape character.\n"
+  "You can also supply the registry path prefix /proc/registry{,32,64}/ 
to\n"
+  "use path completion.\n");
   fprintf (where, ""
   "Example:\n"
-  "%s list '/machine/SOFTWARE/Classes/MIME/Database/Content 
Type/audio\\/wav'\n\n", prog_name);
+  "%s list '/HKLM/SOFTWARE/Classes/MIME/Database/Content 
Type/audio\\/wav'\n\n", prog_name);
 }
   if (where == stderr)
 fprintf (where,
@@ -350,6 +352,15 @@ find_key (int howmanyparts, REGSAM access, int option = 0)
   *h = 0;
   n = e;
 }
+  else if (strncmp ("\\proc\\registry", n, strlen ("\\proc\\registry")) == 0)
+{
+  /* skip /proc/registry{,32,64}/ prefix */
+  n += strlen ("\\proc\\registry");
+  if (strncmp ("64", n, strlen ("64")) == 0)
+n += strlen ("64");
+  else if (strncmp ("32", n, strlen ("32")) == 0)
+n += strlen ("32");
+}
   while (*n != '\\')
 n++;
   *n++ = 0;
-- 
2.21.0



Re: [PATCH] regtool: Ignore /proc/registry{,32,64}/ prefix, with forward or backslashes, allowing path completion

2019-11-11 Thread Corinna Vinschen
On Nov 11 08:30, Brian Inglis wrote:
> On 2019-11-11 02:19, Corinna Vinschen wrote:
> > On Nov 11 10:13, Corinna Vinschen wrote:
> >> On Nov 10 09:14, Brian Inglis wrote:
> >> The patch idea is nice.  Two nits, though.
> >> Please shorten the commit msg summary line and add a bit of descriptive
> >> text instead.
> 
> Sorry, I forget and don't notice longer than standard messages, from using
> 120x60 or larger windows.
> 
> >>> ---
> >>>  winsup/utils/regtool.cc | 13 -
> >>>  1 file changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
> >>> index a44d90768..ddb1304cd 100644
> >>> --- a/winsup/utils/regtool.cc
> >>> +++ b/winsup/utils/regtool.cc
> >>> @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
> >>>"  usersHKU   HKEY_USERS\n"
> >>>"\n"
> >>>"If the keyname starts with a forward slash ('/'), the forward 
> >>> slash is used\n"
> >>> -  "as separator and the backslash can be used as escape 
> >>> character.\n");
> >>> +  "as separator and the backslash can be used as escape character.\n"
> >>> +  "If the keyname starts with /proc/registry{,32,64}/, using forward 
> >>> or backward\n"
> >>> +  "slashes, allowing path completion, that part of the prefix is 
> >>> ignored.\n");
> >>
> >> Is that really essential user information?
> 
> Absolutely essential!
> 
> >> I assume this behaviour is something you just expected to work but then
> >> didn't.  With your patch it now works as you expected.  So it's kind of
> >> a bugfix, rather than a change of behaviour the user needs to learn about.
> 
> To those with similar background or experience it may appear that it should be
> supported, but hasn't been until now.
> 
> It is definitely not expected behaviour, given how regedit, reg, etc. expect
> only hive paths, and how the the current regtool --help reads, clearly 
> expecting
> Windows style backslash separated registry paths, probably pasted within 
> single
> quotes. That expectation is changed somewhat by the forward slash sentence.
> Further changes to expectation needs more documentation.
> 
> >> The above text is, IMHO, more confusing than helpful to a user just
> >> asking for regtool --help.  I'd just drop it.
> 
> It needs documented because it can not in any way be inferred from the 
> existing
> regtool ---help, and would not be expected, that it should work. It was never
> previously supported or seen as helpful or necessary, so it should be seen as 
> a
> non-obvious "surprising" addition, in the opposite sense to "least surprise".
> 
> Please someone suggest better wording for the help, as that is the only
> documentation available, and is needed, to update existing and inform new 
> users.
> Like the code, I tried to maintain the style of the existing help.
> 
> As an alternative, how about:
> "To support path completion, a keyname prefix of /proc/registry{,32,64}/ is
> ignored."

Ok, we can add something to the help text, but the text still sounds
confusing, even the altenative one.  I think the reason is the negative
expression "ignore" here.  Why not express this in a positive way like
this:

  "Use the /proc/registry{,32,64}/ registry path prefix to utilize path
   completion."

Something like that anyway.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature


Re: [PATCH] regtool: Ignore /proc/registry{,32,64}/ prefix, with forward or backslashes, allowing path completion

2019-11-11 Thread Brian Inglis
On 2019-11-11 02:19, Corinna Vinschen wrote:
> On Nov 11 10:13, Corinna Vinschen wrote:
>> On Nov 10 09:14, Brian Inglis wrote:
>> The patch idea is nice.  Two nits, though.
>> Please shorten the commit msg summary line and add a bit of descriptive
>> text instead.

Sorry, I forget and don't notice longer than standard messages, from using
120x60 or larger windows.

>>> ---
>>>  winsup/utils/regtool.cc | 13 -
>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
>>> index a44d90768..ddb1304cd 100644
>>> --- a/winsup/utils/regtool.cc
>>> +++ b/winsup/utils/regtool.cc
>>> @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
>>>"  usersHKU   HKEY_USERS\n"
>>>"\n"
>>>"If the keyname starts with a forward slash ('/'), the forward slash 
>>> is used\n"
>>> -  "as separator and the backslash can be used as escape character.\n");
>>> +  "as separator and the backslash can be used as escape character.\n"
>>> +  "If the keyname starts with /proc/registry{,32,64}/, using forward 
>>> or backward\n"
>>> +  "slashes, allowing path completion, that part of the prefix is 
>>> ignored.\n");
>>
>> Is that really essential user information?

Absolutely essential!

>> I assume this behaviour is something you just expected to work but then
>> didn't.  With your patch it now works as you expected.  So it's kind of
>> a bugfix, rather than a change of behaviour the user needs to learn about.

To those with similar background or experience it may appear that it should be
supported, but hasn't been until now.

It is definitely not expected behaviour, given how regedit, reg, etc. expect
only hive paths, and how the the current regtool --help reads, clearly expecting
Windows style backslash separated registry paths, probably pasted within single
quotes. That expectation is changed somewhat by the forward slash sentence.
Further changes to expectation needs more documentation.

>> The above text is, IMHO, more confusing than helpful to a user just
>> asking for regtool --help.  I'd just drop it.

It needs documented because it can not in any way be inferred from the existing
regtool ---help, and would not be expected, that it should work. It was never
previously supported or seen as helpful or necessary, so it should be seen as a
non-obvious "surprising" addition, in the opposite sense to "least surprise".

Please someone suggest better wording for the help, as that is the only
documentation available, and is needed, to update existing and inform new users.
Like the code, I tried to maintain the style of the existing help.

As an alternative, how about:
"To support path completion, a keyname prefix of /proc/registry{,32,64}/ is
ignored."

> In fact, a descriptive sentence like the above would better serve as
> part of the commit message, methinks :)

I can definitely --amend that as suggested, but still want to ensure some user
documentation of a non-obvious useful feature. New users, and existing users
that don't subscribe to and read all the announcements and news, will never see
anything different.

Are the cygwin-doc html and man pages generated from the regtool.cc help, or are
there any other sources which need updated?
Now rebuilding current cygwin-doc to be able to check: configures and docs take
quite a long while on a desktop.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.

2019-11-11 Thread Michael Haubenwallner
Hi Takashi,

On 11/11/19 10:17 AM, Corinna Vinschen wrote:
> On Nov  8 22:42, Takashi Yano wrote:

>> I came up with another alternative. How about the attached
>> patch? This forcibly redraws screen when the first native
>> program is executed after creating new pty (pseudo console),
>> instead of clearing screen.
>>
>> This does not solve missing screen contents, but can avoid
>> cursor position problem in netsh.
> 
> I tested it and I think this is a great step forward.  Dropping
> $TERM checks and clear screen sequence is the way to go!

I second that!

Your "when the first native program is executed" does lead me to my
next test case with native programs involved, which seems to work
as expected with your patch applied on top of commit d14714c69.

Thanks a lot!
/haubi/
#! /usr/bin/env python

import pty
import os
import select
import subprocess
import sys
import termios

if sys.hexversion >= 0x300:

  def _unicode_encode(s, encoding='utf_8', errors='backslashreplace'):
if isinstance(s, str):
  s = s.encode(encoding, errors)
return s

  def _unicode_decode(s, encoding='utf_8', errors='replace'):
if isinstance(s, bytes):
  s = str(s, encoding=encoding, errors=errors)
return s

  _native_string = _unicode_decode

else:

  def _unicode_encode(s, encoding='utf_8', errors='backslashreplace'):
if isinstance(s, unicode):
  s = s.encode(encoding, errors)
return s

  def _unicode_decode(s, encoding='utf_8', errors='replace'):
if isinstance(s, bytes):
  s = unicode(s, encoding=encoding, errors=errors)
return s

  _native_string = _unicode_encode

def get_term_size(fd=None):
  if fd is None:
fd = sys.stdout
  if not hasattr(fd, 'isatty') or not fd.isatty():
return (0, 0)
  try:
import curses
try:
  curses.setupterm(term=os.environ.get("TERM", "unknown"), fd=fd.fileno())
  return curses.tigetnum('lines'), curses.tigetnum('cols')
except curses.error:
  pass
  except ImportError:
pass
  try:
proc = subprocess.Popen(['/bin/stty', 'size'],
stdout=subprocess.PIPE, stderr=fd)
  except EnvironmentError as e:
if e.errno != errno.ENOENT:
  raise
# stty command not found
return (0, 0)

  out = _unicode_decode(proc.communicate()[0])
  if proc.wait() == os.EX_OK:
out = out.split()
if len(out) == 2:
  try:
val = (int(out[0]), int(out[1]))
  except ValueError:
raise
  else:
if val[0] >= 0 and val[1] >= 0:
  return val
  return (0, 0)

def set_term_size(lines, columns, fd):
  pid = os.fork()
  if pid == 0:
cmd = ['/bin/stty', 'rows', str(lines), 'columns', str(columns)]
os.dup2(0, fd)
os.execvp(cmd[0], cmd)
print("set_term_size failed")
os.exit(1)
  ret = os.waitpid(pid, 0)
  return ret

(masterfd, slavefd) = pty.openpty()

mode = termios.tcgetattr(slavefd)
mode[1] &= ~termios.OPOST
termios.tcsetattr(slavefd, termios.TCSANOW, mode)

if sys.stdout.isatty():
  rows, columns = get_term_size(sys.stdout)
  set_term_size(rows, columns, slavefd)

if os.fork() == 0:
  os.close(masterfd)
  os.dup2(slavefd, 0)
  os.dup2(slavefd, 1)
  os.dup2(slavefd, 2)
  os.execv("/bin/sh", ["/bin/sh","-c", '''
  { cmd /c "set COLUMNS & set LINES & set TERM" ;
"$(/usr/bin/cygpath -F 42)/Microsoft Visual Studio/Installer/vswhere.exe" -nologo -latest -legacy -format text -property installationPath ;
  } 2>&1 | /bin/tr -d r
'''])
  sys.exit(0)

os.close(slavefd)

while True:
  (rlist, wlist, xlist) = select.select([masterfd], [], [masterfd], 100)
  if rlist:
try:
  line = os.read(rlist[0], 1024)
  print(line,)
except OSError as e:
  if (e.errno != 5):
print("quit:",e)
  break
sys.exit(0)


Re: [PATCH] regtool: Ignore /proc/registry{,32,64}/ prefix, with forward or backslashes, allowing path completion

2019-11-11 Thread Corinna Vinschen
On Nov 11 10:13, Corinna Vinschen wrote:
> Hi Brian,
> 
> 
> The patch idea is nice.  Two nits, though.
> 
> Please shorten the commit msg summary line and add a bit of descriptive
> text instead.
> 
> 
> On Nov 10 09:14, Brian Inglis wrote:
> > ---
> >  winsup/utils/regtool.cc | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
> > index a44d90768..ddb1304cd 100644
> > --- a/winsup/utils/regtool.cc
> > +++ b/winsup/utils/regtool.cc
> > @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
> >"  usersHKU   HKEY_USERS\n"
> >"\n"
> >"If the keyname starts with a forward slash ('/'), the forward slash 
> > is used\n"
> > -  "as separator and the backslash can be used as escape character.\n");
> > +  "as separator and the backslash can be used as escape character.\n"
> > +  "If the keyname starts with /proc/registry{,32,64}/, using forward 
> > or backward\n"
> > +  "slashes, allowing path completion, that part of the prefix is 
> > ignored.\n");
> 
> Is that really essential user information?
> 
> I assume this behaviour is something you just expected to work but then
> didn't.  With your patch it now works as you expected.  So it's kind of
> a bugfix, rather than a change of behaviour the user needs to learn about.
> 
> The above text is, IMHO, more confusing than helpful to a user just
> asking for regtool --help.  I'd just drop it.

In fact, a descriptive sentence like the above would better serve as
part of the commit message, methinks :)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature


Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.

2019-11-11 Thread Corinna Vinschen
Hi Takashi,

On Nov  8 22:42, Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 8 Nov 2019 12:09:55 +0100
> Corinna Vinschen wrote:
> > On Oct 24 15:33, Corinna Vinschen wrote:
> > > On Oct 24 19:17, Takashi Yano wrote:
> > > > On Thu, 24 Oct 2019 11:38:17 +0200
> > > > Corinna Vinschen wrote:
> > > > > Well, what I see when starting cmd.exe with this patch is a short
> > > > > flicker in the existing output in mintty, but the cursor position
> > > > > stays the same. and cmd.exe output is where you'd expect it.
> > > > 
> > > > I mean:
> > > > 1) start mintty
> > > > 2) ps
> > > > 3) script
> > > > 4) cmd
> > > > 
> > > > In my environment, output of ps command disappears.
> > > 
> > > In mine, too.  This does not occur w/o running script.
> > 
> > Any news here?  Why does this only occur with script?  Is that something
> > about reusing (or not reusing) the existing pseudo console?
> 
> This does not occur only with script. If you run
> ssh localhost
> instead of script in step 3), it also happens.
> 
> This is because the console screen buffer is empty when pty
> (pseudo console) is started. By executing cmd.exe, screen
> is redrawn based on the console screen buffer. As a result,
> the screen contents which are not in the screen buffer is
> lost.
> 
> I came up with another alternative. How about the attached
> patch? This forcibly redraws screen when the first native
> program is executed after creating new pty (pseudo console),
> instead of clearing screen.
> 
> This does not solve missing screen contents, but can avoid
> cursor position problem in netsh.

I tested it and I think this is a great step forward.  Dropping
$TERM checks and clear screen sequence is the way to go!


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature


Re: [PATCH] regtool: Ignore /proc/registry{,32,64}/ prefix, with forward or backslashes, allowing path completion

2019-11-11 Thread Corinna Vinschen
Hi Brian,


The patch idea is nice.  Two nits, though.

Please shorten the commit msg summary line and add a bit of descriptive
text instead.


On Nov 10 09:14, Brian Inglis wrote:
> ---
>  winsup/utils/regtool.cc | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
> index a44d90768..ddb1304cd 100644
> --- a/winsup/utils/regtool.cc
> +++ b/winsup/utils/regtool.cc
> @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
>"  usersHKU   HKEY_USERS\n"
>"\n"
>"If the keyname starts with a forward slash ('/'), the forward slash 
> is used\n"
> -  "as separator and the backslash can be used as escape character.\n");
> +  "as separator and the backslash can be used as escape character.\n"
> +  "If the keyname starts with /proc/registry{,32,64}/, using forward or 
> backward\n"
> +  "slashes, allowing path completion, that part of the prefix is 
> ignored.\n");

Is that really essential user information?

I assume this behaviour is something you just expected to work but then
didn't.  With your patch it now works as you expected.  So it's kind of
a bugfix, rather than a change of behaviour the user needs to learn about.

The above text is, IMHO, more confusing than helpful to a user just
asking for regtool --help.  I'd just drop it.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature