Re: rvxt-20050409-1 console problem [SUMMARY]
Charles Wilson wrote:
(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.
There is a downside to this. As Brian mentioned run is not going away
-- because without it (e.g. if rxvt[-unicode-X] hides its own console
after-the-fact) you will always get the briefly flashing cmd console.
Not a big deal, but annoying. But, rxvt-unicode-X can't be used with
run if --login (100% CPU suckage). I dug into this, and discovered a
few things:
rxvt-unicode-X has a main event loop that is completely rewritten from
the one in rxvt. So it's not surprising that it behaves somewhat
differently. What's going on in the problematic case (100% CPU usage if
run+urxvt-X+loginShell=true) is that a select() call is always returning
immediately with data waiting -- except that there's not REALLY any
data waiting.
Because run.exe lauches the child process with no console -- not even a
hidden one, actually -- the stdin/stdout/stderr handles are not
initialized. [1] Somewhere -- and I haven't figured out where, yet,
because the obvious place is NOT it -- rxvt-unicode-X is reopening stdin
to /dev/null (well, technically, it's opening file descriptor 0 to the
file /dev/null...it might not be thinking of it in terms of stdin,
per se. dup2() will automatically use the lowest available file
descriptor -- and if 0 [stdin] is available, suddenly you've got stdin
open again.)
Anyway, /dev/null is of course always ready but never actually has any
data. So the event loop never 'hangs out' in the select. Instead, it's
acting like a polling spinlock -- and that's bad.
So, I get the following repeated over and over -- sucking 100% CPU (and
note the second line!).
===
31 447 [main] rxvt 2744 cygwin_select: 7, 0x22EDC0, 0x22EDB8,
0x0, 0x0
52 499 [main] rxvt 2744 dtable::select_read: /dev/null fd 0
49 548 [main] rxvt 2744 dtable::select_read: fd 4
45 593 [main] rxvt 2744 dtable::select_read: /dev/ptmx fd 6
27 620 [main] rxvt 2744 cygwin_select: to NULL, ms
92 712 [main] rxvt 2744 cygwin_select: sel.always_ready 1
24 736 [main] rxvt 2744 select_stuff::cleanup: calling cleanup
routines
20 756 [main] rxvt 2744 socket_cleanup: si 0x0 si-thread 0x0
18 774 [main] rxvt 2744 socket_cleanup: returning
36 810 [main] rxvt 2744 peek_socket: considering handle 0x6D4
23 833 [main] rxvt 2744 peek_socket: adding read fd_set , fd 4
34 867 [main] rxvt 2744 peek_socket: WINSOCK_SELECT returned 0
20 887 [main] rxvt 2744 set_bits: me 0x702AC0, testing fd 0
(/dev/null)
19 906 [main] rxvt 2744 set_bits: ready 1
18 924 [main] rxvt 2744 select_stuff::poll: returning 1
18 942 [main] rxvt 2744 select_stuff::cleanup: calling cleanup
routines
19 961 [main] rxvt 2744 select_stuff::~select_stuff: deleting
select records
671028 [main] rxvt 2744 set_signal_mask: oldmask 0x0, newmask
0x84002, mask_bits 0x0
191047 [main] rxvt 2744 set_signal_mask: not calling
sig_dispatch_pending
211068 [main] rxvt 2744 readv: readv (0, 0x22ED50, 1) blocking,
sigcatchers 3
211089 [main] rxvt 2744 readv: no need to call ready_for_read
201109 [main] rxvt 2744 fhandler_base::read: returning 0, binary
mode
181127 [main] rxvt 2744 readv: 0 = readv (0, 0x22ED50, 1), errno 0
211148 [main] rxvt 2744 set_signal_mask: oldmask 0x84002,
newmask 0x0, mask_bits 0x84002
201168 [main] rxvt 2744 cygwin_select: 7, 0x22EDC0, 0x22EDB8,
0x0, 0x0
===
[1] Here's the important bit from run.exe:
memset (start, 0, sizeof (start));
start.cb = sizeof (start);
start.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
start.wShowWindow = SW_HIDE;
start.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
start.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
start.hStdError = GetStdHandle(STD_ERROR_HANDLE);
sec_attrs.nLength = sizeof (sec_attrs);
sec_attrs.lpSecurityDescriptor = NULL;
sec_attrs.bInheritHandle = FALSE;
if (CreateProcess (NULL, cmdline, sec_attrs, NULL, TRUE, 0,
NULL, NULL, start, child))
{
Sure, it's *supposedly* setting start.hStdInput and friends to The Right
Thing, but according to MSDN (in the AllocConsole() description):
GUI applications are initialized without a console. Console
applications are initialized with a console, unless they are created as
detached processes (by calling the CreateProcess function with the
DETACHED_PROCESS flag).
Since run.exe is a GUI app, it has no console at all -- and therefore
GetStdHandle() returns INVALID_HANDLE_VALUE, which isn't a very nice
thing to initialize start.hStdInput and friends to.
But here's the thing: run.exe's job is to launch an application without
a *visible* console.
Re: rvxt-20050409-1 console problem [SUMMARY]
Charles Wilson wrote: I'm leaning toward this solution, in a more generic sense, like: gui-switcher.exe --config=/etc/rxvt-selector.conf It'll go into the checkX package since it'll leverage a lot of the same code. And that's why I need to track down these issues with rxvt-unicode-X+run+loginShell...'cause if they are not solved with run.exe, they'll show up again with gui-switcher.exe. I know this isn't an ideal solution, but have you considered fork()ing and exec()ing 'checkX' and using wait() to get the return code? That would require your app to have checkX installed but would avoid duplicating the code and/or having to library-ize it (i.e. would be faster to implement). OTOH a lib (or static lib) is generally not a bad idea. -- Matthew Hey, buddy, if it's OT, TITTTL! -- 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/
Re: rvxt-20050409-1 console problem
Shouldn't the console-hiding code be unnecessary? Here is a simple approach that I have been using (and have written to this list previously) which makes it possible to start rxvt without resorting to starting a console first: Using a direct shortcut instead of shortcutting/running the batch file has another advantage, when you're not using rxvt but windows console. Case 1: 1) Run the batch file (through the default cygwin shortcut, via explorer or whatever) which launches bash in a windows console 2) 'exit' the login shell Window closes. All is fine. Case 2: 1) Run the batch file (through a shortuct, via explorer or whatever) which launches bash in a windows console 2) press CTRL-C anytime (shell or not) 3) 'exit' the login shell A message pops up: Terminer le programme de commandes (O/N)? in french (translated: End batch file (Y/N)?). Signal was not only handled by cygwin, but is also handled by the .bat interpreter, which interrupts its execution upon bash return, and ask for interactive confirmation. Stupid, as the .bat is at the end anyway (although it might change its return code). Anyway, that's annoying. Case 3: 1) Run a 'direct' shortcut which launches bash directly (c:\cygwin\bin\bash --login -i), built as it has been suggested and as I did prior to using rxvt or puttycyg. 2) press CTRL-C anytime (shell or not) 3) 'exit' the login shell Window closes. All is fine. Then I switched to rxvt based on this shortcut, and discovered only recently that rxvt pops up a console window and that my shortcut thingie was a heck of a workaround. So I concluded that running .bat files/console was definitely to be promoted on my list of Most Annoying Things Ever. Lloeki
RE: rvxt-20050409-1 console problem [SUMMARY]
1. Thanks for taking on the 'rxvt' package. I look forward to the code changes that will make 'man' pages more readable. (3) (a) add a command line option to say force hide console and use that from scripts 2. I do not have any need for the script usage that you described so I am neutral with respect to whether you add this new feature. If you decide to add the feature, I would suggest that you implement the usual three ways of using it: - highest priority: a command-line switch - next priority: an environment variable - lowest priority: the ~/.rxvt configuration file 3. FWIW, here is a font that I found useful. It has worked on various Windows versions (nt/2k/2003/xp) without any additional steps required on my part (i.e., no additional fonts needed to be installed). It is not mentioned in /usr/share/doc/Cygwin/rxvt-20050409.README. If you find it useful, please feel free to add it to the ones listed in that README file. Simply cutpaste the line to your ~/.Xdefaults. It resizes fairly well with Shift-[num +]/Shift-[num -]. rxvt*font: -outline-Courier New-normal-r-normal-normal-20-96-120-120-c-100-iso8859-1 --- -- 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/
rvxt-20050409-1 console problem
Hi, 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. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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/
Re: rvxt-20050409-1 console problem
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. AFAIK, there are EXE-files that open a console, and others, that don't. It seems, there is a flag in the EXE-files, which determines if Windows should open a console or not. So i always was annoyed by the fact, that starting rxvt directly from windows opens a console windows. Isn't it possible, to create such an EXE-file, that doesn't open a console? Would that cause any problems with cygwin? That would make any hide the console-code unnecessary. Greetings, Sven P.S.: i can reproduce the bug too. signature.asc Description: OpenPGP digital signature
Re: rvxt-20050409-1 console problem
On Mon, 15 May 2006, Sven Köhler 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. AFAIK, there are EXE-files that open a console, and others, that don't. It seems, there is a flag in the EXE-files, which determines if Windows should open a console or not. Well, yes. They are called window mode applications (as opposed to console mode applications). So i always was annoyed by the fact, that starting rxvt directly from windows opens a console windows. Hence the recommended use of run. Isn't it possible, to create such an EXE-file, that doesn't open a console? Would that cause any problems with cygwin? It's possible. But one (important) side effect is that window-mode applications cannot write to a console. So, rxvt --help would be useless if rxvt were to be made a window-mode app. That would make any hide the console-code unnecessary. P.S.: i can reproduce the bug too. Note that my issue is actually the opposite: I start rxvt from an unrelated console, and I *want* that console to stay visible. Looks like the new console-hiding code is a bit over-eager... If I have the time, I'll take a look at the changes to see if there's a simple fix. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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/
Re: rvxt-20050409-1 console problem
Sven Köhler wrote:
AFAIK, there are EXE-files that open a console, and others, that don't.
It seems, there is a flag in the EXE-files, which determines if Windows
should open a console or not.
It is the subsystem flag in the PE header. This can be set by adding
-Wl,--subsystem,windows (aka -Wl,-mwindows) or -Wl,--subsystem,console
(aka -Wl,-mconsole).
http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.SUBSYSTEM.asp
So i always was annoyed by the fact, that starting rxvt directly from
windows opens a console windows.
Use 'run'. Or, modulo the bug Igor is reporting, the latest refresh of
rxvt.
Isn't it possible, to create such an EXE-file, that doesn't open a
console? Would that cause any problems with cygwin?
That would make any hide the console-code unnecessary.
This is not an option in the slightest. A -mwindows application cannot
interact with the console it was invoked from! That means that all such
compiled applications would have no I/O when invoked from the command
line unless redirected to a file. Try compiling int main() {
puts(hello world); } with -mwindows and running it from a windows
console -- you get nothing. -mwindows applications are expected to
either have no console I/O or to explicitly create a new console
themselves. What isn't possible is to attach to the existing console
that it was run from.
Note that I said *windows console*. This means from within CMD.EXE,
without $CYGWIN=tty. If $CYGWIN=tty or you run from rxvt, xterm, over
ssh, then you're using a pty, which is different than a windows console,
and so the discussion is irrelevant.
Note also that Microsoft added an API call in XP and later that lets a
-mwindows compiled application attach to the existing console it was
spawned in. This would allow the desired behavior (no new console
created, but still able to interact with the existing one) but this
would leave all users of nt/2k in the cold -- not an option.
Brian
--
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/
Re: rvxt-20050409-1 console problem
Brian Dessent wrote: This can be set by adding -Wl,--subsystem,windows (aka -Wl,-mwindows) or -Wl,--subsystem,console (aka -Wl,-mconsole). Oops, you don't need -Wl with -mwindows / -mconsole is what I was trying to say here, since they are simply shortcuts defined in the specs file that just end up passing the --subsystem foo flag to the linker. -- 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/
Re: rvxt-20050409-1 console problem
So i always was annoyed by the fact, that starting rxvt directly from windows opens a console windows. Hence the recommended use of run. run? Isn't it possible, to create such an EXE-file, that doesn't open a console? Would that cause any problems with cygwin? It's possible. But one (important) side effect is that window-mode applications cannot write to a console. So, rxvt --help would be useless if rxvt were to be made a window-mode app. Oops, yes. Hmm ... but ... Would rxvt.exe --help work, if you run in from a cygwin-shell? wouldn't that be sufficient? Something that i just noticed: do you have java installed? there is that javaw.exe-thing. It's such a window-mode application. And if i run javaw inside cygwin, then it prints a help-screen to the console! That would make any hide the console-code unnecessary. If there is some other possibility, to hide the console, (what is that run command that you mean?), then i would remove the hide the console-code. There are only two things, that i'd like to be abled to do: a) start rxvt.exe directly from windows without a console-windows b) run it from inside cygwin like any other app P.S.: i can reproduce the bug too. Note that my issue is actually the opposite: I start rxvt from an unrelated console, and I *want* that console to stay visible. Looks like the new console-hiding code is a bit over-eager... If I have the time, I'll take a look at the changes to see if there's a simple fix. Yes, i know. But i thought, that a window-mode application _could_ be a more clean sollution to the problem, because the close the console-code (which is a workaround IMHO) could be removed. signature.asc Description: OpenPGP digital signature
Re: rvxt-20050409-1 console problem
On Mon, 15 May 2006, Sven Köhler wrote: So i always was annoyed by the fact, that starting rxvt directly from windows opens a console windows. Hence the recommended use of run. run? Yes, see http://cygwin.com/packages/run/. Isn't it possible, to create such an EXE-file, that doesn't open a console? Would that cause any problems with cygwin? It's possible. But one (important) side effect is that window-mode applications cannot write to a console. So, rxvt --help would be useless if rxvt were to be made a window-mode app. Oops, yes. Hmm ... but ... Would rxvt.exe --help work, if you run in from a cygwin-shell? wouldn't that be sufficient? Which Cygwin shell? It won't work from a console bash. Something that i just noticed: do you have java installed? there is that javaw.exe-thing. It's such a window-mode application. And if i run javaw inside cygwin, then it prints a help-screen to the console! No, it doesn't, unless you run it from rxvt, xterm, or bash with CYGWIN=tty (in which case, as far as that app is concerned, the output is redirected to a file -- as Brian already mentioned). That would make any hide the console-code unnecessary. If there is some other possibility, to hide the console, (what is that run command that you mean?), then i would remove the hide the console-code. There are only two things, that i'd like to be abled to do: a) start rxvt.exe directly from windows without a console-windows b) run it from inside cygwin like any other app Use run. P.S.: i can reproduce the bug too. Note that my issue is actually the opposite: I start rxvt from an unrelated console, and I *want* that console to stay visible. Looks like the new console-hiding code is a bit over-eager... If I have the time, I'll take a look at the changes to see if there's a simple fix. Yes, i know. But i thought, that a window-mode application _could_ be a more clean sollution to the problem, because the close the console-code (which is a workaround IMHO) could be removed. But at the cost of losing console output -- which is not an option. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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/
Re: rvxt-20050409-1 console problem
So i always was annoyed by the fact, that starting rxvt directly from
windows opens a console windows.
Use 'run'. Or, modulo the bug Igor is reporting, the latest refresh of
rxvt.
Now i know, what you mean with run! Now i'm satisfied, but ...
Isn't it possible, to create such an EXE-file, that doesn't open a
console? Would that cause any problems with cygwin?
That would make any hide the console-code unnecessary.
This is not an option in the slightest. A -mwindows application cannot
interact with the console it was invoked from! That means that all such
compiled applications would have no I/O when invoked from the command
line unless redirected to a file. Try compiling int main() {
puts(hello world); } with -mwindows and running it from a windows
console -- you get nothing. -mwindows applications are expected to
either have no console I/O or to explicitly create a new console
themselves. What isn't possible is to attach to the existing console
that it was run from.
... i have to prove you wrong!
javaw.exe (from sun's java-jre) is a window-mode application, right?
So how can you explain, that i see text within cygwin, when i run javaw.exe?
$ javaw
Usage: javaw [-options] class [args...]
(to execute a class)
or javaw [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-client to select the client VM
-server to select the server VM
-hotspot is a synonym for the client VM [deprecated]
The default VM is client.
See?
It seems to be the standard-behaviour of the windows shell (cmd.exe) to
detach the application from the console if it's starting a window-mode
application. But cygwin doesn't detach the application.
So of course, you're right if you say:
if rxvt would be a window-mode application, then you wouldn't see
anything if you execute rxvt.exe --help from the windows-shell - but i
ask myself, if this is necessary.
signature.asc
Description: OpenPGP digital signature
Re: rvxt-20050409-1 console problem
There are only two things, that i'd like to be abled to do: a) start rxvt.exe directly from windows without a console-windows b) run it from inside cygwin like any other app Use run. So if there is that nice thing called run, that avoids creating a console, do we still need the close the console-code inside rxvt? signature.asc Description: OpenPGP digital signature
Re: rvxt-20050409-1 console problem
This is not an option in the slightest. A -mwindows application cannot
interact with the console it was invoked from! That means that all such
compiled applications would have no I/O when invoked from the command
line unless redirected to a file. Try compiling int main() {
puts(hello world); } with -mwindows and running it from a windows
console -- you get nothing. -mwindows applications are expected to
either have no console I/O or to explicitly create a new console
themselves. What isn't possible is to attach to the existing console
that it was run from.
... i have to prove you wrong!
So it seem, i was wrong. I didn't say anything.
Sorry for the noise.
signature.asc
Description: OpenPGP digital signature
Re: rvxt-20050409-1 console problem
Sven Köhler wrote: So how can you explain, that i see text within cygwin, when i run javaw.exe? $ javaw Usage: javaw [-options] class [args...] Please re-read what I wrote. What you are seeing here is the expected result of *not* using a windows console but instead a pty, which to javaw.exe will appear to be redirection to a pipe. And again, since a pipe does not involve a windows console in any way it is irrelevant. If you try the above from a windows console (this means CMD.EXE, no rxvt, no xterm, no CYGWIN=tty) you get no output whatsoever from javaw.exe. The distinction may not matter to you, but the default Bash shell that Cygwin provides is precisely this, a stock windows console. Brian -- 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/
Re: rvxt-20050409-1 console problem
Sven Köhler wrote: So if there is that nice thing called run, that avoids creating a console, do we still need the close the console-code inside rxvt? Quite the contrary, the console hiding code was just added by Chuck to the recent rxvt refresh so that the extra step of using run would no longer be necessary, or at least this was my understanding. Now in theory without run it will still be impossible to avoid the very brief flicker of a console window before it is hidden, so I suspect run will never really go away. Brian -- 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/
Re: rvxt-20050409-1 console problem
$ javaw Usage: javaw [-options] class [args...] Please re-read what I wrote. What you are seeing here is the expected result of *not* using a windows console but instead a pty, which to javaw.exe will appear to be redirection to a pipe. And again, since a pipe does not involve a windows console in any way it is irrelevant. If you try the above from a windows console (this means CMD.EXE, no rxvt, no xterm, no CYGWIN=tty) you get no output whatsoever from javaw.exe. I'm sorry. I was in a hurry. signature.asc Description: OpenPGP digital signature
RE: rvxt-20050409-1 console problem
Shouldn't the console-hiding code be unnecessary? Here is a simple approach that I have been using (and have written to this list previously) which makes it possible to start rxvt without resorting to starting a console first: 1. Using MS Windows Explorer, locate the 'rxvt' binary in your Cygwin directory tree, for example, at c:\cygwin\bin. 2. Right-click on the 'rxvt.exe' icon and select 'Create Shortcut' from the menu. 3. Right-click on the 'Shortcut to rxvt.exe' icon and select 'Properties' from the menu. 4. In the 'Target' field, type the options that you want to specify for 'rxvt' during startup. For example, C:\cygwin\bin\rxvt.exe -e /bin/bash --login -i tells rxvt to run 'bash' as the shell, and tells bash to run as a login shell. 5. If desired, dragdrop the shortcut icon to your taskbar. Click on the icon to start 'rxvt' without using a console. Am I missing something, or is there still another reason to include the console-hiding code? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Igor Peshansky Sent: Monday, May 15, 2006 10:47 AM To: cygwin@cygwin.com Subject: rvxt-20050409-1 console problem Hi, 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. Igor -- -- 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/
Re: rvxt-20050409-1 console problem
Shouldn't the console-hiding code be unnecessary? Here is a simple approach that I have been using (and have written to this list previously) which makes it possible to start rxvt without resorting to starting a console first: 1. Using MS Windows Explorer, locate the 'rxvt' binary in your Cygwin directory tree, for example, at c:\cygwin\bin. 2. Right-click on the 'rxvt.exe' icon and select 'Create Shortcut' from the menu. 3. Right-click on the 'Shortcut to rxvt.exe' icon and select 'Properties' from the menu. 4. In the 'Target' field, type the options that you want to specify for 'rxvt' during startup. For example, C:\cygwin\bin\rxvt.exe -e /bin/bash --login -i tells rxvt to run 'bash' as the shell, and tells bash to run as a login shell. 5. If desired, dragdrop the shortcut icon to your taskbar. Click on the icon to start 'rxvt' without using a console. Am I missing something, or is there still another reason to include the console-hiding code? You should see it, or perhaps your PC is too fast. But prior to the rxvt windows, another windows opens that gets closed immediatly. That's a console-window like the ones you see, when you run cmd.exe So the console-hiding code is the code, that causes, that the console-window disappears and that inly the rxvt-window remains. signature.asc Description: OpenPGP digital signature
RE: rvxt-20050409-1 console problem
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sven Köhler Sent: Monday, May 15, 2006 12:46 PM To: cygwin@cygwin.com Subject: Re: rvxt-20050409-1 console problem You should see it, or perhaps your PC is too fast. But prior to the rxvt windows, another windows opens that gets closed immediatly. That's a console-window like the ones you see, when you run cmd.exe So the console-hiding code is the code, that causes, that the console-window disappears and that inly the rxvt-window remains. When I start rxvt via the shortcut icon, I see the same behavior regardless of whether I use version 2.7.10-6 or the latest version. So, whatever is happening in the background (console-closing or not) doesn't matter when starting rxvt via the shortcut. The issue, as I understand it, is that some users were starting 'rxvt' from a Cygwin console window (which, in turn, was started via a batch script) by using the command 'run rxvt'. In rxvt 2.7.10-6 and earlier versions, this command sequence would leave the console window displayed. The new console-hiding code causes the console window to be automatically hidden. If the shortcut icon approach to starting rxvt is used, then there is no need (that I know of) to have the console-hiding code included in 'rxvt' because no console would be displayed (or if it is, then it is already automatically hidden). This would then leave the console displayed for those users who need it. --- -- 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/
Re: rvxt-20050409-1 console problem
BTW, isn't is possible to just make the console window created start without SW_VISIBLE? While it would still be created - it would be created invisbly. -cl On Mon, May 15, 2006 at 01:08:07PM -0400, Harig, Mark wrote: The new console-hiding code causes the console window to be automatically hidden. If the shortcut icon approach to starting rxvt is used, then there is no need (that I know of) to have the console-hiding code included in 'rxvt' because no console would be displayed (or if it is, then it is already automatically hidden). This would then leave the console displayed for those users who need it. -- 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/
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
