Command shell window remains open in Windows 7 Beta

[GoogleCodeExporter]

What steps will reproduce the problem?

1. mintty.exe in C:\Program Files\mintty\
2. cygwin installed in C:\cygwin\
3. Shortcut to mintty.exe on Desktop
4. "Target" (desktop shortcut) set to '"C:\Program Files\mintty\mintty.exe"
/bin/bash -l'
5. "Start in" (desktop shortcut) set to 'C:\cygwin\bin'

(single apostrophe (') used for clarity, not used in shortcuts)

What is the expected output? What do you see instead?

MinTTY starts and works as expected. Command window that invokes MinTTY
does not close.

What version of the product are you using? 

Tested on 0.3.3 and 0.3.4

On what operating system?

Windows 7 Beta, build 7000

Original issue reported on code.google.com by erik.berglind.allemann@gmail.com on 15 Jan 2009 at 10:26

Attachments:

• mintty.jpg

[GoogleCodeExporter]

Windows 7 Beta x86 (not tested on x64)

Original comment by erik.berglind.allemann@gmail.com on 15 Jan 2009 at 11:52

[GoogleCodeExporter]

Hi Erik, thanks very much for trying MinTTY on Windows 7 and providing such a
detailed bug report. Clearly there's some sort of incompatibility due to MS 
changing
something in Windows, so the question is, did they change a documented 
behaviour that
should still be the same, or are MinTTY or the Cygwin DLL doing something they
shouldn't be doing.

Is there anything on the "Compatibility" tab of the Shortcut properties that 
makes a
difference to this? Any chance you could use the "Send Feedback" links to try 
and
make MS investigate their side of this?

Apart from that, I guess I ought to be giving 7 a try at some point anyway ...

Original comment by andy.koppe on 15 Jan 2009 at 8:15

• Changed state: Accepted
• Added labels: Priority-Low

[GoogleCodeExporter]

Played around a bit with Compatibility (why didn't I think of that?). 95-Me 
didn't
let the application start, 2000-Vista gives an error message (check screenshot).

Does it tell you anything?

I am running cygwin's stable packages, I could bump them a bit and see where it
lands. What do you think?

Original comment by erik.berglind.allemann@gmail.com on 16 Jan 2009 at 7:20

Attachments:

• mintty-win7-vista-compatibility.jpg

[GoogleCodeExporter]

Apologies for the delay in replying, I'd overlooked your post.

That error message doesn't look like anything mintty-specific; seems that
compatibility mode breaks some of Cygwin's trickery.

I've installed the 7 beta and briefly tried a couple of things, i.e. closing the
standard files and calling FreeConsole(), but to no effect. Curiously, the same
problem has been seen with a 2-year old Cygwin installation on XP (but updating 
to
latest stable cured that one).

So, further experiments needed ...

Original comment by andy.koppe on 31 Jan 2009 at 6:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Still happening on Windows 7 beta build 7057. 

Installed in C:\cygwin\bin\mintty.exe

[sergio@lenobo ~]$ mintty.exe  --version
MinTTY 0.3.8

Original comment by sergio.p...@gmail.com on 26 Mar 2009 at 9:56

[GoogleCodeExporter]

Original comment by andy.koppe on 26 Mar 2009 at 10:14

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

Tested on Windows 7 build 7068 with MinTTY 0.4-alpha1. Same issue. 

Original comment by sergio.p...@gmail.com on 31 Mar 2009 at 3:00

[GoogleCodeExporter]

Closing the extra console ends up closing mintty as well.  However, I 
discovered in
task manager that there's a running conhost.exe associated with mintty, and if 
you
kill that, the console window goes away, with no apparent side effects to the 
mintty.
 I'm half-tempted to throw a "taskkill /F /IM conhost.exe" into my .bashrc...

Still, what happens next is that every new process (cygwin-related or not) 
spawns a
conhost window again, which closes as soon the process exits.  You can start 
running
"cat&" and get as many of these as you like.  These windows steal focus too, 
which
makes this actually worse than just minimizing the original conhost instead of
killing it.

I think this whole problem isn't limited to just mintty though.  I noticed that 
my
sshd service also has a conhost linked to it, though of course I don't see a 
window
since it's a service, not in my session.

BTW, since others have mentioned running cygwin-stable, I should point out that 
I'm
seeing this also on cygwin-1.7.0-44.

Original comment by cuviper on 31 Mar 2009 at 3:22

[GoogleCodeExporter]

Thanks guys for testing this.

It's the child process invoked by mintty for which se7en opens the console. 
Seems MS
suddenly decided that programs for the "console" subsystem should get a console 
when
they're started, and not just when they actually use it, which seems to have 
been the
case before.

xterm is affected by this as well, but rxvt isn't. Turns out rxvt has a 
disgusting
little hack to work around the issue: it opens a console itself and then simply 
hides
its window. Any child processes then inherit that hidden console. So I guess 
this has
been a problem previously (in 9x?), and mintty will just have to do the same.

Original comment by andy.koppe on 31 Mar 2009 at 5:47

• Added labels: Milestone-0.4.0

[GoogleCodeExporter]

I've occasionally seen error messages on that console, like errors with DLL
remapping.  (The perils of running betas...)  So, I wonder if there's some sort 
of
new error channel that the cygwin runtime needs to close or hide.  It's not all
stderr messages, but seemingly the very critical messages go to both stderr and 
the
console window.

Original comment by cuviper on 31 Mar 2009 at 7:01

[GoogleCodeExporter]

Added workaround in r230 on trunk. Annoyingly, the console window still 
flickers up
briefly, unless mintty is invoked from a process with a console (hidden or 
otherwise)
in the first place. This needs investigating in the Cygwin runtime really, as
suggested by cuviper.

Original comment by andy.koppe on 1 Apr 2009 at 10:03

• Changed state: Fixed
• Added labels: Difficulty-Medium

[GoogleCodeExporter]

Thanks Andy! When will this be rolled out in a release? I'm excited to try it. 
I guess 
I could try compiling in the meantime if it's not too complicated on cygwin. 

Original comment by sergio.p...@gmail.com on 2 Apr 2009 at 12:20

[GoogleCodeExporter]

Beta1 is in the download area now.

Original comment by andy.koppe on 2 Apr 2009 at 5:38

[GoogleCodeExporter]

Downloaded the beta1 executable. When launching it from C:\cygwin\bin\ I get 
the 
following pop-up error:

The procedure entry point __ctype_ptr__ could not be located in the dynamic 
link 
library cygwin1.dll.

Original comment by sergio.p...@gmail.com on 2 Apr 2009 at 6:16

[GoogleCodeExporter]

Ah, shouldn't have compiled it on cygwin-1.7. I've replaced the download now. 
Thanks,
Andy

Original comment by andy.koppe on 2 Apr 2009 at 6:33

[GoogleCodeExporter]

Unfortunately I'm still getting the same error.

Original comment by sergio.p...@gmail.com on 2 Apr 2009 at 6:41

[GoogleCodeExporter]

You might have got the old download from cache, as the download counter was 
still on
'0' before I just downloaded it myself.

Original comment by andy.koppe on 2 Apr 2009 at 6:48

[GoogleCodeExporter]

Cool. One step closer. If I run mintty within the cygwin environment (using 
rxvt or 
another mintty windos) it works great. If I launch from Windows (cmd or 
shortcut) I'm 
still getting two windows (one named mintty in the background). I think the 
hack is 
almost there but it'd be nice if I can launch it from a shortcut without 
getting the 
two windows.

Thanks

Original comment by sergio.p...@gmail.com on 2 Apr 2009 at 8:18

[GoogleCodeExporter]

Oh well. There's probably a difference between Cygwin 1.5 and 1.7 then. I'd 
developed
and tested the workaround on Cygwin 1.7 on Win7 only, which wasn't a terribly 
clever
thing to do. Reopening.

Original comment by andy.koppe on 2 Apr 2009 at 11:12

• Changed state: Accepted

[GoogleCodeExporter]

I just installed cygwin 1.7 to test against. I tried both binaries you provided 
last 
night and am seeing the same behavior described in my last post. 

Running cygwin 1.7.0-45  

Original comment by sergio.p...@gmail.com on 2 Apr 2009 at 6:50

[GoogleCodeExporter]

Right, I've tried it on both 1.5 and 1.7 on two different machines with builds 
7000
and 7057 now, and the window hiding works on all of those, so I'm a bit 
stumped. Have
you got any utilities installed that might be interfering?

Has anyone else had a chance to try this?

(Note besides, with 1.5 there seems to be an issue with the main window not
responding for half a minute or so, but that affects rxvt too and appears to be 
a
problem with utmp stamping.)

Original comment by andy.koppe on 2 Apr 2009 at 9:14

[GoogleCodeExporter]

Works for me on build 7000 with cygwin 1.7.  I tried both the shortcut and from 
cmd,
and while I do see the console flash up momentarily, it goes away just fine.

Original comment by cuviper on 3 Apr 2009 at 3:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Are you on 32 or 64bit? I just tested your latest build on fresh installs of 
7057 and 
7068 64bit with cygwin 1.7. Same issue. 

Original comment by sergio.p...@gmail.com on 4 Apr 2009 at 6:13

[GoogleCodeExporter]

I've tried 32-bit only. Perhaps the difference is to do with localisation? The 
system
locale on mine is set to English(UK) on the "Administrative" tab of the 
"Regional and
Language Options" control panel.

Original comment by andy.koppe on 4 Apr 2009 at 7:37

[GoogleCodeExporter]

My locali(z)ation :) is English (United States). I've rebooted using the UK 
locatisation and still nothing. Would I need to reinstall Cygwin after changing 
locatisations to test?

Original comment by sergio.p...@gmail.com on 4 Apr 2009 at 8:08

[GoogleCodeExporter]

Mine is 64-bit, US English...

Original comment by cuviper on 4 Apr 2009 at 8:43

[GoogleCodeExporter]

It's not that then ...

Original comment by andy.koppe on 4 Apr 2009 at 8:49

[GoogleCodeExporter]

I started digging around the cygwin source code a bit.  There's a slightly 
suspicious
bit of code in frok::parent (fork.cc) where it tries see if there's a console by
opening CONOUT$.  I wonder if Windows 7 is seeing that as a need to create a 
console?

Also, in fhandler_console::need_invisible (fhandler_console.cc), they create a 
hidden
console by doing a temporary CreateWindowStation, switch to that, AllocConsole, 
and
switch back.  I wonder if MinTTY's hack could take the same approach, if we 
still
can't figure out the core issue.

Original comment by cuviper on 4 Apr 2009 at 8:02

[GoogleCodeExporter]

Thanks for going digging!

From what I could see, it was the execve in the forked process that triggers the
console to pop up, but only if the call is successful. There's no popup if you 
pass a
dud command. (This is before the r230 hack went in.)

I bet those hacks in Cygwin are to do with earlier problems with popup 
consoles, as
also evidenced by the CONOUT$ hack in rxvt. (For some reason I couldn't get 
that to
work in mintty, which is why I went for the Win2k console functions instead.)

The window station trick sounds like a good idea (even though I'd never heard of
window stations before).

I've actually seen the console popup problem before, with a Cygwin installation 
on XP
that was a few years old, but updating Cygwin cured that. I guess I should 
raise this
whole issue on the Cygwin mailing list, especially as XWin and xterm are 
affected too.

Original comment by andy.koppe on 4 Apr 2009 at 8:58

[GoogleCodeExporter]

Ok, the execve call chain looks something like this:

execve(path, argv, envp)
-> spawnve(mode=_P_OVERLAY, path, argv, envp)
-> spawn_guts(path, argv, envp, mode=_P_OVERLAY)
   [...]
   if (mode == _P_DETACH)
     c_flags |= DETACHED_PROCESS;
   else
     fhandler_console::need_invisible ();
   [...]

So it appears need_invisible is actually the culprit that's not working 
anymore...

Original comment by cuviper on 6 Apr 2009 at 4:41

[GoogleCodeExporter]

Fresh install of latest build 7077 x64 seems to work with 0.4-beta1!! I'm a 
happy 
camper. Thanks for the help.

Original comment by sergio.p...@gmail.com on 10 Apr 2009 at 9:00

[GoogleCodeExporter]

I tried replacing the ShowWindowAsync hack with one based on creating a hidden 
window
station, as suggested by cuviper (to avoid the console flashing up briefly).

Unfortunately it doesn't work: AllocConsole() seems to no longer care about 
whether a
custom window station was selected with SetProcessWindowStation(), and just 
creates
the console window on the default station anyway. Since the Cygwin DLL uses the 
same
trick, this probably is the reason why this whole issue arose in the first 
place.

Original comment by andy.koppe on 15 Apr 2009 at 3:02

[GoogleCodeExporter]

Setting this to "Fixed" in the hope that the issue reported by Sergio really 
has gone
away with build 7077. (Could try periodic polling of GetConsoleWindow() 
otherwise, in
case the console window is actually opened asynchronously.)

Original comment by andy.koppe on 15 Apr 2009 at 6:08

• Changed state: Fixed

[GoogleCodeExporter]

Took fix to 0.3 branch in r247.

Original comment by andy.koppe on 24 Apr 2009 at 8:44

• Added labels: Milestone-0.3.9
• Removed labels: Milestone-0.4.0

[GoogleCodeExporter]

Original comment by andy.koppe on 25 Apr 2009 at 12:03

• Changed state: Verified

[GoogleCodeExporter]

I see similar behavior under Vista Enterprise with the current stable Cygwin
(1.7.2-2) and MinTTY (0.6.1).  The behavior occurs if I launch MinTTY from
Cygwin.bat.  If I create a shortcut to mintty.exe, the second console window is 
not
present.

Original comment by jayburr...@gmail.com on 1 Apr 2010 at 1:27

[GoogleCodeExporter]

Actually this isn't to do with the Windows 7 issue discussed here. When invoking
mintty from a batch script, you need to do so via the 'start' command, 
otherwise your
script won't exit until mintty does, and that's what keeps the console open. 
See also
"Starting mintty from a batch file" in the manual. I'd recommend using a 
shortcut
though, because with the script you'll still get a console flashing up briefly.

Original comment by andy.koppe on 1 Apr 2010 at 4:42

[GoogleCodeExporter]

I just posted in mintty group re using mintty in Task Scheduler.  I'm running 
Win7 Ultimate x64 and do not any start command in this OS (as in previous 
OS's).  Also, if I browse via Task Scheduler to any shortcut, the program 
selected in the target of the shortcut, not the shortcut itself.

I'm using in the Task Scheduler:
Action -> program 
        Program/Script:  C:\cygwin\bin\mintty.exe 
        Add arguments:  -e “/usr/local/bin/XX...csh”
where XX[.].csh is a one-line program that calls  "/usr/local/bin/ 
X[.].csh >& log.XX[.] &". A popup just appears for a fraction of a sec, and 
this is just fine for me. 

Original comment by les...@ingber.com on 13 Oct 2010 at 5:48

[GoogleCodeExporter]

It's neigh 2013 and this issue still exist in mintty 1.1.2 running on Windows 7.

Invoking mintty from a batch file using start results in 2 console windows + 1 
mintty window.
There's a console window for the executing batch file (this will close if you 
let it after the start mintty ...).
Then a conhost console is created.
Then the mintty console is created.
Closing the conhost window kills mintty; terminating conhost appears to leave 
mintty running.

The sub-system must not be set correctly for mintty; it must be set to console 
application but it is a window application.
You can create a console from a window application then setup the redirection 
for the streams (stdin/stdout/stderr) and it should "Just Work".

Original comment by sgbar...@gmail.com on 8 Nov 2012 at 3:36

[GoogleCodeExporter]

The bonus conhost console appears from short-cuts as well.
There are different sorts of short-cuts, this is an area of Windows that I do 
not know well... but the short-cuts created on the desktop & in the start-area 
work but a short-cut created elsewhere does not - it pops up the extra conhost 
console.
I have been unable to determine what is different about the desktop/start 
short-cuts from user-made short-cuts elsewhere that make them work as desired.

Original comment by sgbar...@gmail.com on 8 Nov 2012 at 3:44

[GoogleCodeExporter]

@sgbarber This was fixed in 2009, and if it hadn't, there would have been a lot 
of complaints about it. In Cygwin 1.7, the Cygwin DLL's exec() implementation 
contains a Windows 7-specific hack to create a hidden console, whereas for 
Cygwin 1.5 and MSYS, mintty contains such a hack. Mintty is a Windows subsystem 
application specifically so that no console is created for it.

Please enter a new issue for the problem you're encountering, with Cygwin/MSYS 
version, and step-by-step instructions on how to reproduce it.

Original comment by andy.koppe on 17 Nov 2012 at 1:43

[GoogleCodeExporter]

I just experienced a similar issue and was able to find a solution.

For future reference, "cygwin-console-helper.exe" is required by mintty when 
invoking a shell (i.e. bash). This file is part of cygwin and should be located 
in the /bin directory; it will ensure that the conhost.exe window is 
automatically hidden on startup.

Original comment by dvug...@gmail.com on 14 Jul 2013 at 9:53