This is the mail archive of the
mailing list for the Cygwin project.
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==
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:
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) &&
... 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:
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
"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"
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
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
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
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
## 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? 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
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)?
begin 751 start-rxvt.bat
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html