X-Spam-Check-By: sourceware.org
Message-ID: <44695649.9080001@cwilson.fastmail.fm>
Date: Tue, 16 May 2006 00:34:17 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: rvxt-20050409-1 console problem [SUMMARY]
References: <Pine DOT GSO DOT 4 DOT 63 DOT 0605151043130 DOT 26103 AT access1 DOT cims DOT nyu DOT edu>
In-Reply-To: <Pine.GSO.4.63.0605151043130.26103@access1.cims.nyu.edu>
Content-Type: multipart/mixed;  boundary="------------030401050204060101040600"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

--------------030401050204060101040600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------030401050204060101040600
Content-Type: text/plain;
 name="start-rxvt.bat.uue"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="start-rxvt.bat.uue"

begin 751 start-rxvt.bat
M0&5C:&\@;V9F"E)%30I214T AT 5V%R;FEN9RX@(%1H:7,@8F%T8V@@9FEL92!O
M;FQY('=O<FMS('=I=&@@8VUD+F5X92!F<F]M(`I214T AT 5VEN3E0L(%=I;C)+
M+"!O<B!7:6Y84"`H86YD(&QA=&5R+"!P<F5S=6UA8FQY*2X@($ET('5S97,*
M4D5-(&9E871U<F5S(&YO="!A=F%I;&%B;&4@:6X AT 5VEN DOT 34O5VEN DOT 3@O5VEN
M344N("!)9B!Y;W4 AT 87)E"E)%32!U<VEN9R!T:&]S92!O;&1E<B!/4R=S+"!Y
M;W4@<VAO=6QD(&EN=F]K92!T:&4@=&%R9V5T"E)%32!A<'!L:6-A=&EO;G,@
M*')X=G0N97AE+"!U<GAV=%M\8WQD72U8+F5X92D AT 9&ER96-T;'DN"E)%32!.
M;W1E(&%L<V\@=&AA="!O;B!T:&5S92!O;&1E<B!/4R=S+"!T:&4@=&%R9V5T
M(&%P<&QI8V%T:6]N<PI214T@:&%V92!C;VYS;VQE+6AI9&EN9R!C;V1E('1H
M870@=V]R:W,@;VYL>2!S;&]W;'D@*"=3;&5E<"@T,"DG"E)%32!S96-O;F1S
M*2X AT 66]U<B!B97-T(&)E="!I<R!T;R!U<V4@=&AE(%AS97)V97(L(&AA=F4@
M"E)%32!U<GAV=&0M6"YE>&4@<W1A<G1U<"`H86YD('1A:V4@-#`@<V5C;VYD
M<RD@:6X@>6]U<B!S=&%R='AW:6XN8F%T"E)%32!F:6QE+"!A;F0@=&AE;B!U
M<V4@=7)X=G1C+5 AT N97AE('=H:6-H(&1O97,@;F]T(&AA=F4@=&AE(#0P<V5C
M;VYD"E)%32!D96QA>2X@($]R('5P9W)A9&4@>6]U<B!/4RX*"FEF("(E2$%3
M4TQ!4TA6)2(@/3T@(GEE<R(@9V]T;R`Z0T].5`IS970 AT 2$%34TQ!4TA6/7EE
M<PIS=&%R="!C;60@+W8@+V,@(B4P("4J(@IG;W1O(#I&24Y!3$5.1`H*.D-/
M3E0*"E)%32!C>6-L92!T:')U(&%R9W,@;&]O:VEN9R!F;W(@)RUD('1G="<@
M;W(@+61I<W!L87D@=&=T)PIS970 AT 3$%35%=!4STB(@IF;W(@)25F(&EN("@@
M)2H@*2!D;R!C86QL(#I3151$25-0("4E9 AT I214T@:68@=&AE<F4@=V%S(&$@
M+60@;W(@+61I<W!L87D AT 87)G=6UE;G0L($1)4U!,05D@;F]W(&AO;&1S('1H
M92!V86QU90I214T@;F]W+"!H86YD;&4@<W!E8VEA;"`B;W9E<G)I9&4B('9A
M;'5E(")%35!462(*:68@(B5$25-03$%9)2(@/3T@(D5-4%19(B!S970 AT 1$E3
M4$Q!63T*"E)%32!N;W<@=&AA="!$25-03$%9(&ES('-E="P@=V4 AT 9&]N)W0@
M;F5E9"`G+60 AT 9F]O)R!I;B`E*@I214T@<&QU<RP@=&5L;&EN9R!R>'9T(&ET
M<V5L9B`G+60 AT 14U05%DG('=O=6QD(&)E(&)A9"X@(%-O+`I214T@;75N9V4@
M)2HN+BX*"G-E="!,05-45T%3/0IS970 AT 05)'3$E35#T*9F]R("4E9B!I;B`H
M("4J("D AT 9&\@8V%L;"`Z355.1T535$%2("4E9B`A05)'3$E35"$*4D5-"E)%
M32!F;W(@)25F(&EN("@@)4%21TQ)4U0E("D AT 9&\@96-H;R`E)68*"@IS970@
M0UE'5TE.7U)/3U0]7&-Y9W=I;@IS970 AT 4$%42#TN.R5#64=724Y?4D]/5"5<
M8FEN.R5#64=724Y?4D]/5"5<=7-R7%@Q,5(V7&)I;CLE4$%42"4*"FEF("(E
M1$E34$Q!624B(#T]("(B("`@9V]T;R`Z3D%4259%"FEF("(E1$E34$Q!624B
M(#T]("(Z,"(@9V]T;R`Z3D%4259%"@IC:&5C:U@*:68 AT 15)23U),159%3"`Q
M(&=O=&\@.DY!5$E610H*.E@*4D5-('-T86YD+6%L;VYE('9E<G-I;VX*<W1A
M<G0@=7)X=G0M6"YE>&4@)4%21TQ)4U0E"@I214T AT 8VQI96YT+W-E<G9E<B!V
M97)S:6]N.B!A<W-U;65S('-E<G9E<B!A;')E861Y('-T87)T960*4D5-("AS
M87DL(&)Y('1H92!S=&%R='AW:6X@<V-R:7!T*0I214T@<W1A<G0@=7)X=G1C
M+5 AT N97AE("5!4D=,25-4)0IG;W1O(#I%3D0*"CI.051)5D4*<W1A<G0@<GAV
M="YE>&4@)4%21TQ)4U0E"F=O=&\@.D5.1`H*"@I214T*4D5-('-U8G)O=71I
M;F4@=&%K97,@;VYE(&%R9W5M96YT+B`@57-I;F<@)R!C:&%R86-T97(@=&\@
M<75O=&4*4D5-(&ES('5N=7-U86PL(&)U="!N96-E<W-A<GD@<VEN8V4@=V4@
M97AP96-T(&EN8V]M:6YG(&%R9W,*4D5-('=I=&@@96UB961D960@<W!A8V5S
M('1O(&)E('%U;W1E9"!W:71H("(L(&%N9"`B(FUY=F%L(B(*4D5-(')E86QL
M>2!C;VYF=7-E<R!C;60N97AE"CI3151$25-0"FEF("<E3$%35%=!4R4G(#T]
M("<M9"<@9V]T;R!$3U-%5$1)4U`*:68@)R5,05-45T%3)2<@/3T@)RUD:7-P
M;&%Y)R!G;W1O($1/4T541$E34`IS970 AT 3$%35%=!4STE,0I'3U1/.D5/1 AT HZ
M1$]3151$25-0"G-E="!,05-45T%3/24Q"G-E="!$25-03$%9/24Q"D=/5$\Z
M14]&"E)%32!E;F0@;V8@<W5B<F]U=&EN93L AT 1T]43SI%3T8@:7,@;&EK92`G
M<F5T=7)N)R!F;W(@5TY4+U<R2R]76%`*"@H*4D5-"E)%32!S=6)R;W5T:6YE
M('1A:V5S(&]N92!A<F=U;65N=`HZ355.1T535$%2"FEF("<E3$%35%=!4R4G
M(#T]("<M9"<@9V]T;R!$3TU53D=%4U1!4 AT II9B`G)4Q!4U1705,E)R`]/2`G
M+61I<W!L87DG(&=O=&\@1$]-54Y'15-405(*:68@)R4Q)R`]/2`G+60G(&=O
M=&\@1$]-54Y'15-405(*:68@)R4Q)R`]/2`G+61I<W!L87DG(&=O=&\@1$]-
M54Y'15-405(*<V5T($Q!4U1705,])3$*<V5T($%21TQ)4U0])4%21TQ)4U0E
M("4Q"D=/5$\Z14]&"CI$3TU53D=%4U1!4 AT IS970@3$%35%=!4STE,0I'3U1/
M.D5/1 AT I214T@96YD(&]F('-U8G)O=71I;F4*"@H*"E)%32!E;F0@;V8 AT 9FEL
<90HZ14Y$"E)%32!P875S90HZ1DE.04Q%3D0*"@``
`
end


--------------030401050204060101040600
Content-Type: text/plain; charset=us-ascii

--
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/
--------------030401050204060101040600--