Discussion:
Starting mintty via run.exe
(too old to reply)
John Wiersba
2014-10-16 14:44:53 UTC
Permalink
I'm trying to create a windows shortcut which will start mintty indirectlyby running a (perl) script which will exec mintty. I know I can start mintty.exe directly via the shortcut, but the purpose of my script is to wrap the invocation in the proper environment and arguments.


I'm encountering two problems using run.exe:

1) run.exe doesn't seem to be able to run a hashbang script. My script starts with #!/usr/bin/perl and runs just fine from a cygwin bash command line, starting a new mintty terminal as expected. But calling it from run.exe fails. It flashes some kind of terminal window on the screen, which appears to have no content (but it is hard to tell, since it flashes so quickly) and then the terminal window immediately closes. In this case, my shortcut target is: d:\cygwin\bin\run.exe /path/to/hashbang/script.

2) When I change my shortcut target to: d:\cygwin\run.exe perl /path/to/hashbang/script, then it runs the script and starts a mintty terminal session, but I still get the flashing terminal window before mintty starts, which I don't want. I kind of thought the purpose of run.exe was to hide such a terminal window? There must be something I'm not understanding about how run.exe works or its purpose.


Finally, is there any way I can debug what's going on without rebuilding run.exe? For example, can I prevent the flashing window from flashing so quickly (in case there's a message displayed there).

Thanks!
Eliot Moss
2014-10-16 15:05:26 UTC
Permalink
Post by John Wiersba
I'm trying to create a windows shortcut which will start mintty indirectlyby running a (perl) script which will exec mintty. I know I can start mintty.exe directly via the shortcut, but the purpose of my script is to wrap the invocation in the proper environment and arguments.
1) run.exe doesn't seem to be able to run a hashbang script. My script starts with #!/usr/bin/perl and runs just fine from a cygwin bash command line, starting a new mintty terminal as expected. But calling it from run.exe fails. It flashes some kind of terminal window on the screen, which appears to have no content (but it is hard to tell, since it flashes so quickly) and then the terminal window immediately closes. In this case, my shortcut target is: d:\cygwin\bin\run.exe /path/to/hashbang/script.
I think it may be designed to deal only with actual executables (.exe files).
The wording of the man page is ambiguous, but suggestive of this in that it
speaks of "Windows programs".

So maybe you want: run /bin/bash -c /path/to/hashbang/script

This worked for me with a trival mintty-starting hash-bang bash script.

Regards -- Eliot Moss
John Wiersba
2014-10-16 19:43:50 UTC
Permalink
I'm trying to create a Windows shortcut which will start mintty indirectly by running a (perl) script which will exec mintty. I know I can start mintty.exe directly via the shortcut, but the purpose of my script is to wrap the invocation in the proper environment and arguments.

I'm encountering two problems using run.exe:

1) run.exe doesn't seem to be able to run a hashbang script. My script starts with #!/usr/bin/perl and runs just fine from a cygwin bash command line, starting a new mintty terminal as expected. But calling it from run.exe fails. Clicking on the shortcut flashes some kind of terminal window on the screen, which appears to have no content (but it is hard to tell, since it flashes so quickly) and then the terminal window immediately closes. In this case, my shortcut target is: d:\cygwin\bin\run.exe /path/to/hashbang/script.

2) When I change my shortcut target to: d:\cygwin\run.exe perl /path/to/hashbang/script, then it runs the script and starts a mintty terminal session, but I still get the flashing terminal window before the eventual mintty starts, which I don't want. I thought the purpose of run.exe was to hide such a terminal window? There must be something I'm not understanding about how run.exe works or its purpose.


Finally, is there any way I can debug what's going on without rebuilding run.exe? For example, can I prevent the flashing window from flashing so quickly (in case there's a message displayed there).

Thanks!
Eliot Moss
2014-10-16 23:34:23 UTC
Permalink
Post by John Wiersba
I'm trying to create a Windows shortcut which will start mintty indirectly by running a (perl) script which will exec mintty. I know I can start mintty.exe directly via the shortcut, but the purpose of my script is to wrap the invocation in the proper environment and arguments.
1) run.exe doesn't seem to be able to run a hashbang script. My script starts with #!/usr/bin/perl and runs just fine from a cygwin bash command line, starting a new mintty terminal as expected. But calling it from run.exe fails. Clicking on the shortcut flashes some kind of terminal window on the screen, which appears to have no content (but it is hard to tell, since it flashes so quickly) and then the terminal window immediately closes. In this case, my shortcut target is: d:\cygwin\bin\run.exe /path/to/hashbang/script.
2) When I change my shortcut target to: d:\cygwin\run.exe perl /path/to/hashbang/script, then it runs the script and starts a mintty terminal session, but I still get the flashing terminal window before the eventual mintty starts, which I don't want. I thought the purpose of run.exe was to hide such a terminal window? There must be something I'm not understanding about how run.exe works or its purpose.
Finally, is there any way I can debug what's going on without rebuilding run.exe? For example, can I prevent the flashing window from flashing so quickly (in case there's a message displayed there).
You posted this same question this morning ...

And I answered it about 20 minutes later.

Why are you posting again? You risk annoying the
list subscribers ...

Regards -- Eliot Moss
John Wiersba
2014-10-17 03:39:43 UTC
Permalink
Eliot,

I'm sorry for double posting. I subscribed this morning, sent back the confirmation email, posted my question and...didn't hear anything. I never got my original question from the list nor your reply. Not in my inbox nor in my spam folder. I figured that my question must have somehow been discarded because I wasn't registered on the list yet.

After an hour or two, I tried resubscribing to the list (I was already subscribed) and then reposted my question. I did later see an announcement from Corinna, a post from Ken Brown about emacs and ispell, an announcement from Jon Turney, a post from Christian Franke about exec and PATH, and finally another emacs post from Ken Brown.


I will check the list archives for your reply, since I still don't know what it is. Thanks in advance for your reply.


-- John



----- Original Message -----
Sent: Thursday, October 16, 2014 7:34 PM
Subject: Re: Starting mintty via run.exe
Post by John Wiersba
I'm trying to create a Windows shortcut which will start mintty
indirectly by running a (perl) script which will exec mintty. I know I can
start mintty.exe directly via the shortcut, but the purpose of my script is to
wrap the invocation in the proper environment and arguments.
Post by John Wiersba
1) run.exe doesn't seem to be able to run a hashbang script. My script
starts with #!/usr/bin/perl and runs just fine from a cygwin bash command line,
starting a new mintty terminal as expected. But calling it from run.exe fails.
Clicking on the shortcut flashes some kind of terminal window on the screen,
which appears to have no content (but it is hard to tell, since it flashes so
quickly) and then the terminal window immediately closes. In this case, my
shortcut target is: d:\cygwin\bin\run.exe /path/to/hashbang/script.
Post by John Wiersba
2) When I change my shortcut target to: d:\cygwin\run.exe perl
/path/to/hashbang/script, then it runs the script and starts a mintty terminal
session, but I still get the flashing terminal window before the eventual mintty
starts, which I don't want. I thought the purpose of run.exe was to hide
such a terminal window? There must be something I'm not understanding about
how run.exe works or its purpose.
Post by John Wiersba
Finally, is there any way I can debug what's going on without
rebuilding run.exe? For example, can I prevent the flashing window from
flashing so quickly (in case there's a message displayed there).
You posted this same question this morning ...
And I answered it about 20 minutes later.
Why are you posting again? You risk annoying the
list subscribers ...
Regards -- Eliot Moss
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
John Wiersba
2014-10-17 03:51:03 UTC
Permalink
Post by John Wiersba
----- Original Message -----
Subject: Re: Starting mintty via run.exe
I think it may be designed to deal only with actual executables (.exe files).
The wording of the man page is ambiguous, but suggestive of this in that it
speaks of "Windows programs".
So maybe you want: run /bin/bash -c /path/to/hashbang/script
This worked for me with a trival mintty-starting hash-bang bash script.
Regards -- Eliot Moss
I found your reply on the mailing list archives and quoted it above. Yes, the same approach worked for me (in my original question I used perl rather than bash -c, since my script was written in perl). That's mainly an annoyance that I have to specify the interpreter directly, rather than use the shebang line. But I'm trying to get confirmation that it's not a "bug" but rather the way run.exe was designed.


However, do you have any ideas about the flashing window which appears and then immediately disappears before the mintty terminal starts? That's a show-stopper. I thought that was what run.exe was supposed to prevent by making that console window hidden? Do you get the same flashing console window with your trivial mintty-starting script?


-- John



----- Original Message -----
Post by John Wiersba
Sent: Thursday, October 16, 2014 11:39 PM
Subject: Re: Starting mintty via run.exe
Eliot,
I'm sorry for double posting. I subscribed this morning, sent back the
confirmation email, posted my question and...didn't hear anything. I never
got my original question from the list nor your reply. Not in my inbox nor in
my spam folder. I figured that my question must have somehow been discarded
because I wasn't registered on the list yet.
After an hour or two, I tried resubscribing to the list (I was already
subscribed) and then reposted my question. I did later see an announcement from
Corinna, a post from Ken Brown about emacs and ispell, an announcement from Jon
Turney, a post from Christian Franke about exec and PATH, and finally another
emacs post from Ken Brown.
I will check the list archives for your reply, since I still don't know what
it is. Thanks in advance for your reply.
-- John
----- Original Message -----
Sent: Thursday, October 16, 2014 7:34 PM
Subject: Re: Starting mintty via run.exe
Post by John Wiersba
I'm trying to create a Windows shortcut which will start mintty
indirectly by running a (perl) script which will exec mintty. I know I can
start mintty.exe directly via the shortcut, but the purpose of my script is
to
wrap the invocation in the proper environment and arguments.
Post by John Wiersba
1) run.exe doesn't seem to be able to run a hashbang script. My
script
starts with #!/usr/bin/perl and runs just fine from a cygwin bash command
line,
starting a new mintty terminal as expected. But calling it from run.exe
fails.
Clicking on the shortcut flashes some kind of terminal window on the
screen,
which appears to have no content (but it is hard to tell, since it flashes
so
quickly) and then the terminal window immediately closes. In this case, my
shortcut target is: d:\cygwin\bin\run.exe
/path/to/hashbang/script.
Post by John Wiersba
2) When I change my shortcut target to: d:\cygwin\run.exe
perl
/path/to/hashbang/script, then it runs the script and starts a mintty
terminal
session, but I still get the flashing terminal window before the eventual
mintty
starts, which I don't want. I thought the purpose of run.exe was to
hide
such a terminal window? There must be something I'm not understanding
about
how run.exe works or its purpose.
Post by John Wiersba
Finally, is there any way I can debug what's going on without
rebuilding run.exe? For example, can I prevent the flashing window from
flashing so quickly (in case there's a message displayed there).
You posted this same question this morning ...
And I answered it about 20 minutes later.
Why are you posting again? You risk annoying the
list subscribers ...
Regards -- Eliot Moss
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Eliot Moss
2014-10-17 13:14:32 UTC
Permalink
Post by John Wiersba
Post by Eliot Moss
So maybe you want: run /bin/bash -c /path/to/hashbang/script
This worked for me with a trival mintty-starting hash-bang bash script.
I found your reply on the mailing list archives and quoted it above. Yes,
the same approach worked for me (in my original question I used perl rather
than bash -c, since my script was written in perl). That's mainly an
annoyance that I have to specify the interpreter directly, rather than use
the shebang line. But I'm trying to get confirmation that it's not a "bug"
but rather the way run.exe was designed.
I guess the author will have to confirm, but #! behavior is something built in
to the system calls in Unix, and is likely provided in a little bit different
manner under cygwin. I am not sure what run.exe would have to do to make it
happen -- maybe add its own functionality to look for and parse a #! line.
Post by John Wiersba
However, do you have any ideas about the flashing window which appears and
then immediately disappears before the mintty terminal starts? That's a
show-stopper. I thought that was what run.exe was supposed to prevent by
making that console window hidden? Do you get the same flashing console
window with your trivial mintty-starting script?
Sorry, no -- I think I have seen that myself some in the past. The
author/maintainer of run.exe will probably have to answer these.

By the way, you could create a copy of run.exe called runperl.exe (or maybe
just a link with that name) and it will run perl, as documented in the man
page for run.

Regards -- Eliot
John Wiersba
2014-10-17 21:52:09 UTC
Permalink
With a 3-week-old (i.e. recent) install of cygwin, which otherwise functions well:

$ uname -a
CYGWIN_NT-6.1 DESKTOP-NAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin



$ PATH=/bin:/usr/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:37:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D:\cygwin\bin
D:\cygwin\bin
Segmentation fault


Also, I notice that when PATH has no :, cygcheck prints bogus information:
$ PATH=/bin cygcheck -s

Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:38:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D
\cygwin\bin
Segmentation fault


Running under gdb:

$ PATH=/bin gdb cygcheck
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cygcheck...(no debugging symbols found)...done.
(gdb) r -s
Starting program: /bin/cygcheck -s
[New Thread 5492.0x11ec]

Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:46:49 2014

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path: D
\cygwin\bin
[Inferior 1 (process 5492) exited with code 030000000005]
(gdb)


All of this was in preparation for reporting another problem with run.exe (which flashes a console window instead of hiding it).

Thanks!
Marco Atzeri
2014-10-18 03:59:30 UTC
Permalink
Post by John Wiersba
$ uname -a
CYGWIN_NT-6.1 DESKTOP-NAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
$ PATH=/bin:/usr/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:37:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D:\cygwin\bin
D:\cygwin\bin
Segmentation fault
it works fine here
$ PATH=/bin:/usr/bin cygcheck -s

Cygwin Configuration Diagnostics
Current System Time: Sat Oct 18 04:49:42 2014

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path: E:\cygwin64\bin
E:\cygwin64\bin

Output from E:\cygwin64\bin\id.exe
...
zlib0 1.2.8-1 OK

also from CMD prompt no issue.
Post by John Wiersba
$ PATH=/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:38:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D
\cygwin\bin
Segmentation fault
$ PATH=/bin gdb cygcheck
[cut]
Post by John Wiersba
(gdb) r -s
Starting program: /bin/cygcheck -s
[New Thread 5492.0x11ec]
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:46:49 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D
\cygwin\bin
[Inferior 1 (process 5492) exited with code 030000000005]
(gdb)
BLODA ?
Post by John Wiersba
All of this was in preparation for reporting another problem with run.exe (which flashes a console window instead of hiding it).
Thanks!
John Wiersba
2014-10-20 22:39:22 UTC
Permalink
Apparently not BLODA (plus I'm not running anything on the BLODA list).


Instead, I found that COMSPEC needs to be set in the environment or I get a segfault as shown in my previous email below. I don't know why that is, but I can easily demonstrate it.



----- Original Message -----
Sent: Friday, October 17, 2014 11:59 PM
Subject: Re: cygcheck -s segfaults in cygwin64 on Win7Pro-64
Post by John Wiersba
With a 3-week-old (i.e. recent) install of cygwin, which otherwise
$ uname -a
CYGWIN_NT-6.1 DESKTOP-NAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
$ PATH=/bin:/usr/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:37:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D:\cygwin\bin
D:\cygwin\bin
Segmentation fault
it works fine here
$ PATH=/bin:/usr/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Sat Oct 18 04:49:42 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: E:\cygwin64\bin
E:\cygwin64\bin
Output from E:\cygwin64\bin\id.exe
...
zlib0 1.2.8-1 OK
also from CMD prompt no issue.
Post by John Wiersba
$ PATH=/bin cygcheck -s
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:38:27 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D
\cygwin\bin
Segmentation fault
$ PATH=/bin gdb cygcheck
[cut]
Post by John Wiersba
(gdb) r -s
Starting program: /bin/cygcheck -s
[New Thread 5492.0x11ec]
Cygwin Configuration Diagnostics
Current System Time: Fri Oct 17 17:46:49 2014
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Path: D
\cygwin\bin
[Inferior 1 (process 5492) exited with code 030000000005]
(gdb)
BLODA ?
Post by John Wiersba
All of this was in preparation for reporting another problem with run.exe
(which flashes a console window instead of hiding it).
Post by John Wiersba
Thanks!
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Andrew Schulman
2014-10-21 08:03:31 UTC
Permalink
Post by John Wiersba
Instead, I found that COMSPEC needs to be set in the environment or I get a
segfault as shown in my previous email below. I don't know why that is,
but I can easily demonstrate it.
Confirmed here. I had actually already seen this segfault too, but I
hadn't figured out it was caused by empty COMSPEC.
Corinna Vinschen
2014-10-21 11:03:10 UTC
Permalink
Post by Andrew Schulman
Post by John Wiersba
Instead, I found that COMSPEC needs to be set in the environment or I get a
segfault as shown in my previous email below. I don't know why that is,
but I can easily demonstrate it.
Confirmed here. I had actually already seen this segfault too, but I
hadn't figured out it was caused by empty COMSPEC.
That's interesting. I just debugged this a bit. As you know, cygcheck
is a native Windows application (it's supposed to work even if Cygwin
is entirely broken).

At one point it tries to fetch information about the installed services
by calling cygrunsrv --list --verbose. It tries to accomplish that by
calling the MSVCRT version of popen(2). And it's that call to popen
which crashes if COMSPEC is not set, or not set correctly.

I applied a patch to cygcheck, which enforces setting COMSPEC if the
variable is unset. That doesn't help against *wrong* settings of COMSPEC,
but that's really user's fault alone, I think :)

I also created a new snapshot on https://cygwin.com/snapshots/ which
comes with a cygcheck containing that patch.


HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
John Wiersba
2014-10-21 15:28:42 UTC
Permalink
Post by Corinna Vinschen
I also created a new snapshot
on https://cygwin.com/snapshots/ which
comes with a cygcheck containing that patch.
Thanks, Corinna! Now I can get back to debugging my real issue! :-)
John Wiersba
2014-10-21 16:51:56 UTC
Permalink
I'm trying to use run.exe to avoid a flashing console window, but it is not working on my cygwin64 install on Win7Pro-64. This is a fresh install from 10/20/2014. I've attached my cygcheck.out. I've tried the following windows shortcuts and all cause a console window to briefly flash (in the case of mintty a console window flashes before the mintty terminal is displayed).

D:\cygwin\bin\run.exe /bin/bash -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc


Since hiding the console window is the main purpose of run.exe, it seems that it is badly broken for Win7Pro-64.
Andrey Repin
2014-10-22 13:36:00 UTC
Permalink
Greetings, John Wiersba!
Post by John Wiersba
I'm trying to use run.exe to avoid a flashing console window, but it is not
working on my cygwin64 install on Win7Pro-64. This is a fresh install from
10/20/2014. I've attached my cygcheck.out. I've tried the following
windows shortcuts and all cause a console window to briefly flash (in the
case of mintty a console window flashes before the mintty terminal is displayed).
D:\cygwin\bin\run.exe /bin/bash -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc
Since hiding the console window is the main purpose of run.exe, it seems
that it is badly broken for Win7Pro-64.
Can you tell, what is that console? I.e. what's in it's header?


--
WBR,
Andrey Repin (***@yandex.ru) 22.10.2014, <17:35>

Sorry for my terrible english...
John Wiersba
2014-10-22 20:34:53 UTC
Permalink
Andrey, the flashing console flashes very quickly and I don't know how to slow it down.
It appears to have no title and no contents.

I gave up on using the bash option -c, because of clashes due to mixing windows and

linux command line parsing conventions. So, instead I created a script /d/try:

export PATH=/bin
sleep 10
date >>/d/out.txt # cygdrive is /

Here are the results of my recent tests:

When I run:

D:\cygwin\bin\run.exe /bin/bash --norc /d/try
then there is a flashing console window which closes immediately. It appears to have no title or
contents but it's hard to tell since it flashes so quickly. In the process list of Process

Explorer (from Microsoft's SysInternals), I can see:

1) conhost.exe "Console Window Host" (nested under csrss.exe "Client Server Runtime Process"))
2) bash.exe (at the top level)

3) sleep.exe (at the top level)

After the expected 10 seconds, the processes disappear and the file /d/out.txt gets written to.

If I run instead:

D:\cygwin\bin\bash.exe --norc /d/try
I get an empty console window (which doesn't close immediately), with the same title as my

shortcut name. This console window closes after the specified 10 seconds. In this case, there

is a slight change in the processes running:

1) conhost.exe "Console Window Host" (nested under csrss.exe "Client Server Runtime Process"))
2) bash.exe (running under explorer.exe "Windows Explorer")
3) sleep.exe (at the top level)


So, definitely, run.exe is *not* preventing the flashing console window as I expected it to.
________________________________
Sent: Wednesday, October 22, 2014 9:36 AM
Subject: Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Greetings, John Wiersba!
Post by John Wiersba
I'm trying to use run.exe to avoid a flashing console window, but it is not
working on my cygwin64 install on Win7Pro-64. This is a fresh install from
10/20/2014. I've attached my cygcheck.out. I've tried the following
windows shortcuts and all cause a console window to briefly flash (in the
case of mintty a console window flashes before the mintty terminal is displayed).
D:\cygwin\bin\run.exe /bin/bash -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc
Since hiding the console window is the main purpose of run.exe, it seems
that it is badly broken for Win7Pro-64.
Can you tell, what is that console? I.e. what's in it's header?
--
WBR,
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Doug Henderson
2014-10-23 00:19:39 UTC
Permalink
Post by John Wiersba
Andrey, the flashing console flashes very quickly and I don't know how to slow it down.
It appears to have no title and no contents.
run appears to work correctly when you use it at a cygwin shell prompt.

run.exe is a cygwin executable; use ldd see the DLLs that it uses.

Since your shortcut is not starting a windows GUI program, it starts a
console window, possibly executing cmd.exe

It is this console windows where cmd.exe executes run.exe that you see
flashing on the screen.

Have you tried changing the shortcut to cause it to open the window
minimized? I vaguely remember doing something like that with the
cygwin.bat clone I used to start a (non-X windows) rxvt window.

Doug
--
Doug Henderson, Calgary, Alberta, Canada
Andrey Repin
2014-10-23 01:28:33 UTC
Permalink
Greetings, Doug Henderson!
Post by Doug Henderson
Post by John Wiersba
Andrey, the flashing console flashes very quickly and I don't know how to slow it down.
It appears to have no title and no contents.
Normally, I just fire up a screen recorder in such cases. But I seems to have
missed the beginning of a discussion.
Post by Doug Henderson
run appears to work correctly when you use it at a cygwin shell prompt.
run.exe is a cygwin executable; use ldd see the DLLs that it uses.
Since your shortcut is not starting a windows GUI program, it starts a
console window, possibly executing cmd.exe
Depends on the way shortcut is constructed... I don't think it ever touch
cmd.exe, there's no need to do so. But the console window is really the
run.exe itself. Most, if not all, of Cygwin applications are in fact "console
applications" in Windows terms.
Post by Doug Henderson
Have you tried changing the shortcut to cause it to open the window
minimized? I vaguely remember doing something like that with the
cygwin.bat clone I used to start a (non-X windows) rxvt window.
That may at least alleviate the window flashing in the face of a user.


--
WBR,
Andrey Repin (***@yandex.ru) 23.10.2014, <5:25>

Sorry for my terrible english...
Andrew Schulman
2014-10-23 08:42:01 UTC
Permalink
Post by Andrey Repin
Post by Doug Henderson
Have you tried changing the shortcut to cause it to open the window
minimized? I vaguely remember doing something like that with the
cygwin.bat clone I used to start a (non-X windows) rxvt window.
That may at least alleviate the window flashing in the face of a user.
Yeah, that does seem to help. Thanks.
John Wiersba
2014-10-23 12:24:19 UTC
Permalink
Sent: Wednesday, October 22, 2014 9:28 PM
Subject: Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Post by Doug Henderson
Post by John Wiersba
Andrey, the flashing console flashes very quickly and I don't know how to slow it down.
It appears to have no title and no contents.
Normally, I just fire up a screen recorder in such cases. But I seems to have
missed the beginning of a discussion.
Post by Doug Henderson
run appears to work correctly when you use it at a cygwin shell prompt.
run.exe is a cygwin executable; use ldd see the DLLs that it uses.
Since your shortcut is not starting a windows GUI program, it starts a
console window, possibly executing cmd.exe
Depends on the way shortcut is constructed... I don't think it ever touch
cmd.exe, there's no need to do so. But the console window is really the
run.exe itself. Most, if not all, of Cygwin applications are in fact "console
applications" in Windows terms.
Post by Doug Henderson
Have you tried changing the shortcut to cause it to open the window
minimized? I vaguely remember doing something like that with the
cygwin.bat clone I used to start a (non-X windows) rxvt window.
That may at least alleviate the window flashing in the face of a user.
Maybe I'm confused. Isn't the purpose of run.exe to start a
cygwin program without creating a (visible) console window?
I can just start a cygwin program directly without the indirection of
run.exe if I don't care about the random flashing console window.

From the run.exe manpage:
run will do this for you. It works as intermediate and starts a program but makes the console window hidden.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Achim Gratz
2014-10-23 17:56:18 UTC
Permalink
Post by John Wiersba
Maybe I'm confused. Isn't the purpose of run.exe to start a
cygwin program without creating a (visible) console window?
The purpose of run is to start a Windows program that needs a console to
exist and hide the console window created by windows if there is no
console that the program can attach to (which would otherwise clutter
the taskbar even when minimized).
Post by John Wiersba
I can just start a cygwin program directly without the indirection of
run.exe if I don't care about the random flashing console window.
What are you actually trying to do? Starting mintty from a Windows
shortcut doesn't produce a console window to start with and you can just
tell mintty what program you intend to run inside it.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
John Wiersba
2014-10-23 18:44:42 UTC
Permalink
________________________________
Post by John Wiersba
Maybe I'm confused. Isn't the purpose of run.exe to start a
cygwin program without creating a (visible) console window?
The purpose of run is to start a Windows program that needs a console to
exist and hide the console window created by windows if there is no
console that the program can attach to (which would otherwise clutter
the taskbar even when minimized).
I believe this fits what I am trying to do. Start a console program (/bin/bash.exe)
without a console being visible, even for a short period of time.
Post by John Wiersba
I can just start a cygwin program directly without the indirection of
run.exe if I don't care about the random flashing console window.
What are you actually trying to do? Starting mintty from a Windows
shortcut doesn't produce a console window to start with and you can just
tell mintty what program you intend to run inside it.
My scenario is to eventually start mintty. But I want to script up the

arguments to mintty so I didn't have to type them into the windows shortcut.

I created a shortcut:

d:\cygwin\bin\run.exe /bin/bash.exe script.sh

(I would prefer: d:\cyginw\run.exe script.sh, but that doesn't work for
some reason)


where script.sh eventually starts mintty with some command line arguments.

However, I don't want the flashing window before the bash script calls mintty.

Run.exe flashes a console window before (or in the process of) starting bash.

If I don't use run.exe and instead start bash.exe directly with


d:\cygwin\bin\bash.exe script.sh

I get an extra console window. So, run.exe is successfully getting rid of that

extra console window, but in the process it flashes the console window, which

is what I'm trying to get rid of (and I think might be a bug in run.exe).

Additionally, I have other scenarios where I would like to start bash from a

windows shortcut without a flashing console window, even though run.exe is
successful in not leaving a console window on the taskbar.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Doug Henderson
2014-10-23 18:34:34 UTC
Permalink
Post by John Wiersba
Maybe I'm confused. Isn't the purpose of run.exe to start a
cygwin program without creating a (visible) console window?
I can just start a cygwin program directly without the indirection of
run.exe if I don't care about the random flashing console window.
run will do this for you. It works as intermediate and starts a program but makes the console window hidden.
AFAIK, all programs that run in Windows need a window handle in order
to receive events, and to pass to a lot of windows functions. If your
program create a windows before it tries to do anything that requires
a window, that window gets used. When your program does not create its
own windows, the start up code tries to attach you to an existing
console window, and if there is not one, it creates it.

A Windows GUI program starts at winmain(). This entry point does not
have the same requirements as the C standard main() entry point.
Mainly, you do not have the stdin, stdout, and stderr attached to
anything, and you do not have a window. Creating a console or GUI
window is entirely up to your code.

Normally, any non-GUI program will attach to the console window where
it starts. A "dos" type program will attach to the window running the
cmd.exe that started it, and a cygwin program will get attached to the
mintty console window to which your shell is attached,

For both types of non-GUI programs, the msvcrt.dll or cygwin1.dll
runtime code will setup stdin, stdout and stderr before entering
main(). The runtime startup code will create a console window for you
if you did not inherit one from your parent process, and the code will
attach those file pointers to the console window

In any system: Windows, cygwin, linux, or whatever, to create a
windowless process, you close those initial file pointers or file
handles and fork a new process. In the original process, you close
your window if necessary, you call exit(), and the runtime will close
your window if necessary. In the new process, you do what ever you
want.

When you have a cmd.exe window, you use "start" to fire off a new
program and control what happens to its window with command line
options.
When you have a shell in a cygwin console, you use "run.exe" at the
shell prompt.
When you use a shortcut, you have not initial window, so the
msvcrt.dll runtime creates one for you, and uses the properties of the
shortcut to control how that window is created.

At the shell prompt, try the following commands:

$ /cygdrive/c/windows/system32/notepad.exe

$ /cygdrive/c/windows/system32/notepad.exe &

$ run /cygdrive/c/windows/system32/notepad.exe

$ run /cygdrive/c/windows/system32/notepad.exe &

use ps to check how the notepad process is connected to cygwin. Try
exiting the shell after the second command to see why you want to use
run.

Anyway, that's how I think things work. But I may be wrong. It may
give you some ideas on where to look for more correct and/or detailed
answers.

Doug
--
Doug Henderson, Calgary, Alberta, Canada

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
John Wiersba
2014-10-23 19:12:28 UTC
Permalink
Thanks, Doug.

I use cygstart.exe to start windows programs (such as winword or notepad) from

a mintty/bash console in a way that allows the mintty console to be closed

while the windows application is still active.


I thought run.exe was meant to be used from shortcuts to run cygwin programs

without flashing a console window on the desktop. I don't think it's needed
to start programs from a mintty console.
________________________________
Sent: Thursday, October 23, 2014 2:34 PM
Subject: Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Post by John Wiersba
Maybe I'm confused. Isn't the purpose of run.exe to start a
cygwin program without creating a (visible) console window?
I can just start a cygwin program directly without the indirection of
run.exe if I don't care about the random flashing console window.
run will do this for you. It works as intermediate and starts a program
but makes the console window hidden.
AFAIK, all programs that run in Windows need a window handle in order
to receive events, and to pass to a lot of windows functions. If your
program create a windows before it tries to do anything that requires
a window, that window gets used. When your program does not create its
own windows, the start up code tries to attach you to an existing
console window, and if there is not one, it creates it.
A Windows GUI program starts at winmain(). This entry point does not
have the same requirements as the C standard main() entry point.
Mainly, you do not have the stdin, stdout, and stderr attached to
anything, and you do not have a window. Creating a console or GUI
window is entirely up to your code.
Normally, any non-GUI program will attach to the console window where
it starts. A "dos" type program will attach to the window running the
cmd.exe that started it, and a cygwin program will get attached to the
mintty console window to which your shell is attached,
For both types of non-GUI programs, the msvcrt.dll or cygwin1.dll
runtime code will setup stdin, stdout and stderr before entering
main(). The runtime startup code will create a console window for you
if you did not inherit one from your parent process, and the code will
attach those file pointers to the console window
In any system: Windows, cygwin, linux, or whatever, to create a
windowless process, you close those initial file pointers or file
handles and fork a new process. In the original process, you close
your window if necessary, you call exit(), and the runtime will close
your window if necessary. In the new process, you do what ever you
want.
When you have a cmd.exe window, you use "start" to fire off a new
program and control what happens to its window with command line
options.
When you have a shell in a cygwin console, you use "run.exe" at the
shell prompt.
When you use a shortcut, you have not initial window, so the
msvcrt.dll runtime creates one for you, and uses the properties of the
shortcut to control how that window is created.
$ /cygdrive/c/windows/system32/notepad.exe
$ /cygdrive/c/windows/system32/notepad.exe &
$ run /cygdrive/c/windows/system32/notepad.exe
$ run /cygdrive/c/windows/system32/notepad.exe &
use ps to check how the notepad process is connected to cygwin. Try
exiting the shell after the second command to see why you want to use
run.
Anyway, that's how I think things work. But I may be wrong. It may
give you some ideas on where to look for more correct and/or detailed
answers.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Doug Henderson
2014-10-23 19:40:10 UTC
Permalink
Post by John Wiersba
I'm trying to use run.exe to avoid a flashing console window, but it is not working on my cygwin64 install on Win7Pro-64. This is a fresh install from 10/20/2014. I've attached my cygcheck.out. I've tried the following windows shortcuts and all cause a console window to briefly flash (in the case of mintty a console window flashes before the mintty terminal is displayed).
D:\cygwin\bin\run.exe /bin/bash -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc
Since hiding the console window is the main purpose of run.exe, it seems that it is badly broken for Win7Pro-64.
Short answer: minimize the shortcut window.

Long answer: In windows explorer, right click on the shortcut and
select "Properties" from the context menu (it's the last item). On the
"Shortcut" tab (it's the default tab), change the value of the drop
down labeled "Run:" from "Normal window" to "Minimized". Click "OK".

Now, that flashing window will open minimized, which is much less
noticeable. It may not even paint on the task bar before the mintty
window opens. On my machine, the mintty icon paints to the right of a
blank icon space, and immediately slides left to abut the previous
icons on the task bar. If your task bar is hidden, you may not even
see that.

For clarity, let me describe the process for creating your shortcut:
In windows explorer, right click in a directory (i.e. the right pane),
select "New" -> "Shortcut". In the frst panel of the shortcut wizard,
enter "D:\cygwin\bin\run.exe" as the location. At this point you can
only enter the name of the executable without command line arguments.
Click "Next" and in the second panel of the shortcut wizard, enter a
name for the shortcut and click "OK". Now right click on the shortcut
and select "Properties". On the "Shortcut" tab, change the Target:"
text box to add arguments to the exe's command line, so the box
contains "D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash
--norc". You could also change the target to "D:\cygwin\bin\env.exe -i
PATH=/bin mintty bash --norc" with equivalent result. Or even
"D:\cygwin64\bin\mintty.exe ./env.exe -i PATH=/bin bash --norc", now
you set "Run:" to "Normal window".

BTW, this search may help to discover how to create a shortcut from
the command line.

https://www.google.com/search?q=create+windows+shortcut+command+line

Doug
--
Doug Henderson, Calgary, Alberta, Canada

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
John Wiersba
2014-10-23 20:24:04 UTC
Permalink
Post by Doug Henderson
Post by John Wiersba
I'm trying to use run.exe to avoid a flashing console window, but it is not working on
my cygwin64 install on Win7Pro-64. This is a fresh install from 10/20/2014. I've
attached my cygcheck.out. I've tried the following windows shortcuts and all cause a
console window to briefly flash (in the case of mintty a console window flashes before
the mintty terminal is displayed).
D:\cygwin\bin\run.exe /bin/bash -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi"
D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc
Since hiding the console window is the main purpose of run.exe, it seems that it is
badly broken for Win7Pro-64.
Short answer: minimize the shortcut window.
Long answer: In windows explorer, right click on the shortcut and
...
Thanks, Doug. I did that (minimize the shortcut) which makes it almost unnoticeable.
That's an acceptable work-around for me.

Is this not a bug in run.exe? Run.exe documents a hidden console window, but it sounds
like "flashing and then hidden console window, unless you externally minimize the window
by minimizing the shortcut" would be a more accurate description. Perhaps there no
(easy) way of run.exe doing this?

Is there a use-case for run.exe besides its use in shortcuts? If not, then it would be
even more handy for run.exe to do the minimizing/fully-hiding of the console window.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Achim Gratz
2014-10-23 20:52:40 UTC
Permalink
Post by John Wiersba
Is this not a bug in run.exe?
No, if anything it's a bug in Windows. Look in the archives at the
beginning of 2009 where this was discussed. You can at least hide the
window after it exists now, but the option of starting it out of sight
has been removed with Windows 7 and not returned best I know.
Post by John Wiersba
Run.exe documents a hidden console window, but it sounds
like "flashing and then hidden console window, unless you externally minimize the window
by minimizing the shortcut" would be a more accurate description. Perhaps there no
(easy) way of run.exe doing this?
It does hide the console window at the earliest possible moment.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
John Wiersba
2014-10-23 21:25:23 UTC
Permalink
Thank you -- that clears up a lot of my confusion.



----- Original Message -----
Sent: Thursday, October 23, 2014 4:52 PM
Subject: Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Post by John Wiersba
Is this not a bug in run.exe?
No, if anything it's a bug in Windows. Look in the archives at the
beginning of 2009 where this was discussed. You can at least hide the
window after it exists now, but the option of starting it out of sight
has been removed with Windows 7 and not returned best I know.
Post by John Wiersba
Run.exe documents a hidden console window, but it sounds
like "flashing and then hidden console window, unless you externally
minimize the window
Post by John Wiersba
by minimizing the shortcut" would be a more accurate description.
Perhaps there no
Post by John Wiersba
(easy) way of run.exe doing this?
It does hide the console window at the earliest possible moment.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Continue reading on narkive:
Loading...