This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rvxt-20050409-1 console problem [SUMMARY]

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

begin 751 start-rxvt.bat
M0&5C:&\@;V9F"E)%30I214T@5V%R;FEN9RX@(%1H:7,@8F%T8V@@9FEL92!O
M;FQY('=O<FMS('=I=&@@8VUD+F5X92!F<F]M(`I214T@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@5VEN.34O5VEN.3@O5VEN
M344N("!)9B!Y;W4@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@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@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@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@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@3$%35%=!4STB(@IF;W(@)25F(&EN("@@
M)2H@*2!D;R!C86QL(#I3151$25-0("4E9@I214T@:68@=&AE<F4@=V%S(&$@
M+60@;W(@+61I<W!L87D@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@1$E3
M4$Q!63T*"E)%32!N;W<@=&AA="!$25-03$%9(&ES('-E="P@=V4@9&]N)W0@
M;F5E9"`G+60@9F]O)R!I;B`E*@I214T@<&QU<RP@=&5L;&EN9R!R>'9T(&ET
M<V5L9B`G+60@14U05%DG('=O=6QD(&)E(&)A9"X@(%-O+`I214T@;75N9V4@
M)2HN+BX*"G-E="!,05-45T%3/0IS970@05)'3$E35#T*9F]R("4E9B!I;B`H
M("4J("D@9&\@8V%L;"`Z355.1T535$%2("4E9B`A05)'3$E35"$*4D5-"E)%
M32!F;W(@)25F(&EN("@@)4%21TQ)4U0E("D@9&\@96-H;R`E)68*"@IS970@
M0UE'5TE.7U)/3U0]7&-Y9W=I;@IS970@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@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@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@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@3$%35%=!4STE,0I'3U1/.D5/1@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@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@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@IS970@3$%35%=!4STE,0I'3U1/
M.D5/1@I214T@96YD(&]F('-U8G)O=71I;F4*"@H*"E)%32!E;F0@;V8@9FEL
<90HZ14Y$"E)%32!P875S90HZ1DE.04Q%3D0*"@``
`
end


--
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/
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]