rvxt-20050409-1 console problem [SUMMARY]

[Charles Wilson]

Igor Peshansky wrote:
> After installing rxvt-20050409-1, starting rxvt from a console bash hides
> that console.  To reproduce: start a console bash, type "rxvt" or "rxvt &"
> (either way), observe that the bash window goes away (the process is still
> running, though).  I don't think the cygcheck output is relevant, since
> this looks like an rxvt problem (caused by the new code to hide the
> console).  Chuck, if you can't reproduce this, please let me know and I'll
> provide more details.

Nope, don't need to reproduce it -- it's an obvious (now!) effect of the 
code.  I've got an idea for a solution to this problem I've created, but 
first I want to address some misconceptions downthread.

======
(1) Brian Dessent was 99.9% right in this message 
(http://cygwin.com/ml/cygwin/2006-05/msg00376.html).  100% if you take 
the correction in his immediate followup.

If CYGWIN contains tty (set BEFORE the bash shell is started; e.g. via 
the Windows Environment), then you're using ptys.  -mwindows apps (like 
javaw) can communicate with the console, but only if they like ptys. 
Not all of them do (C:\Windows\system32\ftp.exe does not, for example).

If you're using rxvt or ssh, then you're using ptys.

However, if you're using PLAIN OLD CMD.EXE *and* CYGWIN does not contain 
tty, THEN, and ONLY then, are you actually using direct console I/O.  In 
this scenario, -mwindows do not HAVE console I/O, so they cannot 
communicate with the spawning console.  (unless they use the XP API to 
reconnect, as Brian mentioned).  Since neither of those two options are 
acceptable, -mwindows is not allowed.

======
(2) So, we've had rxvt for years, and run.exe for years, and this combo 
has worked just fine.  rxvt is a -mconsole app, it can talk to the 
spawning console (rxvt --help works) regardless of 
cmd.exe/CYGWIN=tty/rxvt/whathaveyou).  However, if launched via a 
shortcut from the Windows Environment (Start Menu, Desktop, Explorer, 
etc), it will create a dummy cmd.exe window -- because it is an 
-mconsole app, and that's what they do. [* errm, not really.  See ==1== 
below]

Well, as one poster suggested, you could create the console window with 
!SW_VISIBLE.  The problem with that idea, is that by the time you've got 
control the console has already been created!  So, what you do, is 
OPTIONALLY -- e.g. when you don't care about interaction with the 
spawning console, like if you're double-clicking a windows shortcut -- 
use a helper application that is compiled -mwindows.  It can then create 
a hidden (!SW_VISIBLE) console, and pass that console to the client 
application by launching the client directly using the WindowsAPI 
CreateProcess, instead of cygwin's spawn/exec/family.

Well, that's exactly what run.exe does.

Another alterative is for rxvt to hide the console after it is launched 
(but this leads to a briefly flashing cmd.exe window). [*] ==1==

=====

So, until now, if you're (manually) launching rxvt from a console -- 
whether an rxvt/xterm one, a cmd.exe+CYGWIN=tty one, or a 
cmd.exe+CYGWIN=notty one -- then you simply call rxvt.exe directly.  It 
just works.  And your console -- even if it was a cmd+CYGWIN=notty one 
-- did not disappear on you.  I broke this when cmd+CYGWIN=notty.  Oops.

If you wanted to launch rxvt from the "Windows Environment", you used 
run.exe to launch the rxvt indirectly.  That just works. (There is no 
cmd.exe window, not even a briefly flashing one).

[*] The following was news to me, but I've verified it and dug into the 
code to figure out why.  Mark Harig was correct here:
http://cygwin.com/ml/cygwin/2006-05/msg00386.html

It turns out that if you launch rxvt directly from the windows 
environment, it -- even before I messed with it -- will follow the 
procedure above at ==1==.  It turns out that the libW11 wrapper code in 
rxvt-2.7.10-6 already has a variant of the hide_console code.  It 
differs from the new code I added in that it has some kind of test to 
see if its associated console was spawned in response to its own launch, 
or if it pre-existed.  In the former case (e.g. you double clicked a 
shortcut and Windows launched the process with an associated console) it 
would hide the console -- after the obligatory brief flash.  In the 
latter case -- the console was already there, and you manually typed 
'rxvt' or whatever -- then it would NOT hide the console.  Pretty slick:

   hConsole = CreateFile( "CONOUT$",
      GENERIC_WRITE | GENERIC_READ,
      FILE_SHARE_READ | FILE_SHARE_WRITE, &sa,
      OPEN_EXISTING, 0, 0 );
   if (GetConsoleScreenBufferInfo(hConsole,&buffInfo) &&
                 buffInfo.dwCursorPosition.X==0 &&
                 buffInfo.dwCursorPosition.Y==0)
   {
       ... only then, do we hide the console ...
   }

=====

So why did I bother?  Well, 'cause (a) I didn't know about the above; I 
always got cmd.exe boxes because I always launched rxvt via a script, 
not directly, and (b) I *wanted* to be able to launch rxvt via windows 
shortcut to a script and STILL be able to hide the console.

Why not just revert to the old behavior?  Well, maybe we will, but...

...the answer is here:
http://cygwin.com/ml/cygwin-apps/2006-03/msg00119.html
http://cygwin.com/ml/cygwin-apps/2006-03/msg00122.html
and
http://cygwin.com/ml/cygwin-apps/2006-03/msg00133.html

Ultimately, I want a script (.bat or .sh) that can mimic what the 
current split-personality rxvt does: when DISPLAY is set to a usable 
Xserver, run **some rxvt binary** which is an Xclient.  Otherwise, run 
**some other rxvt binary** which is a pure native windows app.

e.g. I want users to "pretend" they still have a split personality rxvt, 
but actually provide the capability via two separate applications.  I'd 
prefer to use a script to call two clients, so that users could 
customize it:

"I want plain old rxvt for native windows, and urxvtc for X"
"I want rxvt-unicode-W for native windows, and urxvt for X"
"I'm old school, I want plain old rxvt for both native and X"

etc.

But here's the problem: if you have a script (like, say, the one 
attached and uuencoded to protect against overzealous anti-v filters) 
and you launch that script via a shortcut -- then you're stuck with the 
console window that the script ran in!   This is true even with the 
pre-existing hideConsole code in old-rxvt.  (Basically, the "pretty 
slick" code in old-rxvt can't distinguish between "this console was just 
created in order for the batch script that launched me" and "this 
console belongs to an interactive bash/cmd window".  But that's 
hindsight; I didn't even realize the old-rxvt had any hide-console code 
at all.)

So, in my ignorance, I added hide-the-console code to both 
rxvt-unicode-X and to the new version of rxvt.  And it worked great! 
The (fairly complicated) batch file below does just like I wanted -- on 
NT/2K/XP.  (Okay, I get *two* briefly flashing windows, but that's just 
because I can't guarantee that the user has set
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions
true, so I relaunch cmd.exe with the /v switch.  I've got a bash version 
of the same script that only flashes *one* window).

======

I never thought of users like Igor.  The current situation is clearly 
untenable.

======

So, here's a possible solution:

(1) revert rxvt back to old behavior with "smart" hide console code (but 
which won't be able to hide the console if launched via a script, like 
the one below).

(2) add the "smart" hide console code to rxvt-unicode-X and remove the 
brute-force hide console code.  Otherwise, the Igors of the world will 
have the same "where'd my console go" problem with rxvt-unicode-X.

(3) (a) add a command line option to say "force hide console" and use 
that from scripts

(3) (b) forget about scripts.  Use a special version of "run" 
specifically for the purpose of switching between rxvt versions.  For 
user customizability, maybe it could read configuration info

---
nativeGUI: /usr/bin/rxvt.exe
X11: /usr/bin/urxvtc.exe

## use these to override ~/.Xdefaults
## try not to conflict with ACTUAL cmdline args given to rxvt-launcher
## because it's indeterminate which one of a conflicting set will
## actually have effect.
nativeGUI-options: -fn "Lucida ConsoleP-16" -tn rxvt-native-cygwin
X11-options: -fn "--some-X11-XLFN" -tn rxvt-unicode
---

from a file in /etc.  This rxvt-launcher would be a -mwindows app, just 
like run.  It would use the checkX program (or borrow the code; sigh. 
Time for a library?) to determine Xness, and launch the apropriate 
client using !SW_VISIBLE, just like run.  But it wouldn't have any of 
run's introspection code ("what was my own argv[0]?  Did it match 
'run?????.exe' where ????? non-empty?  Search PATH for ?????.) nor would 
it need to have any PATH walking code at all -- require that 
configuration info contain full PATH.  (It would need to resolve 
symlinks, tho).

=====

Okay, I think I've covered all the bases in this thread, explained the 
history of this change, and laid out a proposed solution going forward. 
  Comments?  Suggestions between 3(a) and 3(b)?

--
Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: start-rxvt.bat.uue
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060516/d5682f6d/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/