This is all very interesting, and responds to a question that I raised
-- but it's been overcome by events. In run-1.1.12, we no longer care
whether the current process's (that is, run's) GetStdHandles are from a
console or not -- not even in commented-out code.
Instead, we care whether the curr
Christopher Faylor wrote:
> Is there something wrong with Cygwin's code for determining if a handle is a
> console?
>
> ...
> if (GetConsoleScreenBufferInfo (handle, &buf))
> {
> ...
> }
> else if (GetNumberOfConsoleInputEvents (handle, (DWORD *) &buf))
> {
> ...
>
On Thu, Aug 20, 2009 at 07:07:21AM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Dave Korn on 8/20/2009 7:11 AM:
>> Eric Blake wrote:
>>
>>> See this thread on the gnulib list, which claims that you can use this
>>> undocumented snippet to decide whether
On Thu, Aug 20, 2009 at 02:11:06PM +0100, Dave Korn wrote:
>Eric Blake wrote:
>
>> See this thread on the gnulib list, which claims that you can use this
>> undocumented snippet to decide whether a HANDLE is a console:
>>
>>> #define IsHandleConsole(h) (((long) (h) & 3) == 3)
>>
>> http://lists.g
Eric Blake wrote:
> At any rate, Bruno also had this suggestion in that thread:
>
> static BOOL
> IsHandleConsole(HANDLE h)
> {
> DWORD mode;
> return GetConsoleMode (h, &mode);
> }
So, on the one hand, we have an officially-documented function, specified
and guaranteed by MSDN. And on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dave Korn on 8/20/2009 7:11 AM:
> Eric Blake wrote:
>
>> See this thread on the gnulib list, which claims that you can use this
>> undocumented snippet to decide whether a HANDLE is a console:
>>
>>> #define IsHandleConsole(h) (((long) (h
Eric Blake wrote:
> See this thread on the gnulib list, which claims that you can use this
> undocumented snippet to decide whether a HANDLE is a console:
>
>> #define IsHandleConsole(h) (((long) (h) & 3) == 3)
>
> http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00065.html
I wouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Charles Wilson on 8/17/2009 12:42 PM:
> Okay, so here's another idea:
>
> And in configure_startupinfo():
>
> /* foo() is some magic mechanism for determining that the HANDLEs
> * returned by GetStdHandle() are from a console, a
Corinna Vinschen wrote:
> Big big big sigh.
>
> And a big sorry for the hassle.
>
> My only excuse is that I'm currently distracted by another project at my
> company.
>
> It turns out that all three attempts, starting with my NUL: patch, over
> your previous one, up to this one work fine in all
On 8/17/2009 6:39 PM, Charles Wilson wrote:
Charles Wilson wrote:
If we already HAVE true console handles, then we shouldn't FreeConsole
and try to recreate our own...
OK, how about this? Seems to work on Vista(cyg1.5, cyg1.7, mingw) x
gui/cui/bat.
This is probably irrelevant in view of Co
On Aug 17 14:09, Ken Brown wrote:
> On 8/17/2009 12:36 PM, Corinna Vinschen wrote:
>> On Aug 17 11:36, Charles Wilson wrote:
>>> Corinna Vinschen wrote:
>>>
Oh well. The above shortcut as well as your startxwin.bat script don't
work on W7. Only a shortcut like this
C:\cygwin
On Aug 17 18:39, Charles Wilson wrote:
> Charles Wilson wrote:
>
> > If we already HAVE true console handles, then we shouldn't FreeConsole
> > and try to recreate our own...
>
> OK, how about this? Seems to work on Vista(cyg1.5, cyg1.7, mingw) x
> gui/cui/bat.
>
> The basic idea is to try and
Hi,
Chuck wrote:
> OK, how about this? Seems to work on Vista(cyg1.5, cyg1.7, mingw)
xgui/cui/bat.
Applied your latest patch to run's cvs and built with MinGW, for native
Windows.
Works for me on Windows 2003 Server.
Tested as before and with 'run CUIs' in batch files (*.bat) and shortcut
file
CGF wrote:
" On Mon, Aug 17, 2009 at 07:16:17PM +0100, Robin Walker wrote:
" >--On 17 August 2009 17:52 + Stephan Mueller wrote:
" >
" >> Robin Walker wrote:
" >> " On any NT-class Windows, calling a *.bat file causes a 16-bit
" >> sub-system to " be spawned, and the .bat file is interpreted
Charles Wilson wrote:
> If we already HAVE true console handles, then we shouldn't FreeConsole
> and try to recreate our own...
OK, how about this? Seems to work on Vista(cyg1.5, cyg1.7, mingw) x
gui/cui/bat.
The basic idea is to try and re-use whatever console is available, if
any, when run is
Colin Harrison wrote:
> Hi,
>
> Chuck wrote:
>> So, here's another approach that seems to work for me
>
> I needed to #include to compile this with MinGW (to find
> SHGFI_EXETYPE)
>
> However, then I get (on Windows 2003) an 'Unable to write to standard error'
> with my CUI plink.
Okay, so her
On Mon, Aug 17, 2009 at 07:16:17PM +0100, Robin Walker wrote:
>--On 17 August 2009 17:52 + Stephan Mueller wrote:
>
>> Robin Walker wrote:
>> " On any NT-class Windows, calling a *.bat file causes a 16-bit
>> sub-system to " be spawned, and the .bat file is interpreted within the
>> 16-bit com
--On 17 August 2009 17:52 + Stephan Mueller wrote:
Robin Walker wrote:
" On any NT-class Windows, calling a *.bat file causes a 16-bit
sub-system to " be spawned, and the .bat file is interpreted within the
16-bit command " interpreter.
"
" Given that Cygwin 1.7 no longer supports Windows
On 8/17/2009 12:36 PM, Corinna Vinschen wrote:
On Aug 17 11:36, Charles Wilson wrote:
Corinna Vinschen wrote:
Oh well. The above shortcut as well as your startxwin.bat script don't
work on W7. Only a shortcut like this
C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0
works and
Robin Walker wrote:
" --On 17 August 2009 15:57 +0200 Corinna Vinschen wrote:
" > The [...] as well as your startxwin.bat script don't work on W7.
" On any NT-class Windows, calling a *.bat file causes a 16-bit sub-system to
" be spawned, and the .bat file is interpreted within the 16-bit command
Hi,
Chuck wrote:
> So, here's another approach that seems to work for me
I needed to #include to compile this with MinGW (to find
SHGFI_EXETYPE)
However, then I get (on Windows 2003) an 'Unable to write to standard error'
with my CUI plink.
Thanks,
Colin
--
Problem reports: http://cyg
--On 17 August 2009 15:57 +0200 Corinna Vinschen wrote:
The [...] as well as your startxwin.bat script don't work on W7.
On any NT-class Windows, calling a *.bat file causes a 16-bit sub-system to
be spawned, and the .bat file is interpreted within the 16-bit command
interpreter.
Given tha
On Aug 17 11:36, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > Oh well. The above shortcut as well as your startxwin.bat script don't
> > work on W7. Only a shortcut like this
> >
> > C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0
> >
> > works and allows to start emacs.
Corinna Vinschen wrote:
> Oh well. The above shortcut as well as your startxwin.bat script don't
> work on W7. Only a shortcut like this
>
> C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0
>
> works and allows to start emacs.
So, here's another approach that seems to work for me
On Aug 17 08:18, Ken Brown wrote:
> On 8/17/2009 4:47 AM, Corinna Vinschen wrote:
>> I'm not sure this a generic enough solution, there's probable more
>> necessary. However, would others be so kind to test this on non-W7
>> systems as well as with other applications like emacs?
>
> Works for me o
On 8/17/2009 4:47 AM, Corinna Vinschen wrote:
On Aug 16 12:55, Charles Wilson wrote:
Colin Harrison wrote:
I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
(1.1.11 run + your patch)
bForceUsingPipes = (os_version >= 0x0501);
#$!%#
I made this = FALSE to fix for 2003 ser
Hi,
Corinna wrote:
> However, would others be so kind to test this on non-W7 systems
I built run from cvs + Corinna's patch with MinGW (for native Windows) and
tested on Windows 2003 server.
Tests OK for me..my Big List Of Dodgy CUIs appear to be happy bunnies now :)
Thanks,
Colin
--
Problem r
On Aug 16 12:55, Charles Wilson wrote:
> Colin Harrison wrote:
> > I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
> > (1.1.11 run + your patch)
> > bForceUsingPipes = (os_version >= 0x0501);
>
> #$!%#
>
> > I made this = FALSE to fix for 2003 server..not tried on Windows 7
Colin Harrison wrote:
> I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
> (1.1.11 run + your patch)
> bForceUsingPipes = (os_version >= 0x0501);
#$!%#
> I made this = FALSE to fix for 2003 server..not tried on Windows 7.
> I'm still testing (run built with MinGW) so this is
Hi,
Chuck wrote:
> However, a lot of folks are used to using the run.exe tool
I for one.
I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
(1.1.11 run + your patch)
bForceUsingPipes = (os_version >= 0x0501);
I made this = FALSE to fix for 2003 server..not tried on Windows 7.
Colin Harrison wrote:
> //test.js
> //JavaScript to display xeyes without a local Command Prompt...
> var wshell = new ActiveXObject('WScript.Shell');
> wshell.Run('"C:\\Program Files\\Xming\\xeyes.exe" -display :2',0);
>
> It's the '0' that does the magic.
Yep, I've even got an implementation i
Corinna Vinschen wrote:
>> Do you think this idea is worth pursuing?
>
> Sounds like a good idea to me. I'm just wondering, is there really
> no easy Win32 function to fetch this information, along the lines
> of the GetBinaryType function?
Well, there's SHGetFileInfo with the SHGFI_EXETYPE fla
Hi,
You probably know this, but a JavaScript file can be used to do something
similar to the Run Utility for Windows CUIs...
//test.js
//JavaScript to display xeyes without a local Command Prompt...
var wshell = new ActiveXObject('WScript.Shell');
wshell.Run('"C:\\Program Files\\Xming\\xeyes.exe"
On Aug 15 10:46, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Apparently `run XWin' doesn't work at all anymore, everything else seems
> > to work fine. A shortcut starting XWin directly w/o run works fine as
> > well. Is XWin allergic against the pipe redirection, maybe?
>
> Hmm. I've be
On 8/15/2009 10:46 AM, Charles Wilson wrote:
It seems that emacs.exe (and even emacs-X11,exe) are both console
programs,...
Just for the record, so that emacs users don't get confused, the current
emacs and emacs-X11 packages in cygwin-1.7 don't provide an emacs.exe.
The emacs package provide
Corinna Vinschen wrote:
> On Aug 14 17:39, Ken Brown wrote:
>> On 8/14/2009 2:48 PM, Corinna Vinschen wrote:
Given that the X server shortcut is just a `run /usr/bin/startxwin.bat',
is it possible that the new incarnation doesn't start cmd correctly?
>>> I built with -DDEBUG and it appear
2009/8/15 Corinna Vinschen:
> Apparently `run XWin' doesn't work at all anymore, everything else seems
> to work fine. A shortcut starting XWin directly w/o run works fine as
well.
XWin is a GUI subsystem program, hence it doesn't need 'run'. (But of
course it ought to work anyway.)
Andy
--
Prob
On Aug 14 17:39, Ken Brown wrote:
> On 8/14/2009 2:48 PM, Corinna Vinschen wrote:
>> On Aug 14 20:41, Corinna Vinschen wrote:
>>> On Aug 14 14:16, Charles Wilson wrote:
Charles Wilson wrote:
Corinna, can you give this a try? (I'm happy to send you a compiled
version of the modified r
On 8/14/2009 2:48 PM, Corinna Vinschen wrote:
On Aug 14 20:41, Corinna Vinschen wrote:
On Aug 14 14:16, Charles Wilson wrote:
Charles Wilson wrote:
Corinna, can you give this a try? (I'm happy to send you a compiled
version of the modified run.exe if that helps).
I just built it myself, and th
On Aug 14 20:41, Corinna Vinschen wrote:
> On Aug 14 14:16, Charles Wilson wrote:
> > Charles Wilson wrote:
> > Corinna, can you give this a try? (I'm happy to send you a compiled
> > version of the modified run.exe if that helps).
>
> I just built it myself, and this looks pretty good. I can sta
On Aug 14 14:16, Charles Wilson wrote:
> Charles Wilson wrote:
> > Corinna Vinschen wrote:
> >> Actually, what I told above is nonsense anyway. What I saw was the
> >> flickering cmd window from a urxvt-X startup without run. With run it
> >> doesn't start at all for me on W7, unless I start it f
On 8/14/2009 2:08 PM, Charles Wilson wrote:
Ken Brown wrote:
On 8/14/2009 12:50 PM, Charles Wilson wrote:
Yeah. I think the core issue is that run takes care to hook up stdin &
friends to the child process, but that something is going wrong in that
process when CREATE_NO_WINDOW -- and, for wha
Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Actually, what I told above is nonsense anyway. What I saw was the
>> flickering cmd window from a urxvt-X startup without run. With run it
>> doesn't start at all for me on W7, unless I start it from an existing
>> console window. And in that c
Ken Brown wrote:
> On 8/14/2009 12:50 PM, Charles Wilson wrote:
>> Yeah. I think the core issue is that run takes care to hook up stdin &
>> friends to the child process, but that something is going wrong in that
>> process when CREATE_NO_WINDOW -- and, for whatever reason, urxvt[d]-X
>> needs tha
On 8/14/2009 12:50 PM, Charles Wilson wrote:
Yeah. I think the core issue is that run takes care to hook up stdin &
friends to the child process, but that something is going wrong in that
process when CREATE_NO_WINDOW -- and, for whatever reason, urxvt[d]-X
needs that (maybe also Ken Brown's bat
Corinna Vinschen wrote:
> Actually, what I told above is nonsense anyway. What I saw was the
> flickering cmd window from a urxvt-X startup without run. With run it
> doesn't start at all for me on W7, unless I start it from an existing
> console window. And in that case it doesn't matter if the
Christopher Faylor wrote:
> I know I should be downloading sources and inspecting things rather than
> making obvious suggestions but I don't suppose that urxvt calls
> FreeConsole?
only in force_visible_console(), which is dead code unless debugging.
--
Chuck
--
Problem reports: http://c
Corinna Vinschen wrote:
> I just tested this further. If you omit the CREATE_NO_WINDOW flag
> to CreateProcess, the console window still flickers when starting
> urxvt, but the CPU usage does not stick to 100%. Since XWin and
> xterm are apparently unaffected by this (no flickering cmd window)
>
Christopher Faylor wrote:
> Isn't just creating the process with SW_HIDE good enough?
In general, no -- because run already does that. I'm sure that was one
of the very first things the earliest implementations of run did
(actually, a quick glance says that's the only thing run-1.1.3 did to
make
On Aug 14 11:43, Christopher Faylor wrote:
> On Fri, Aug 14, 2009 at 05:29:04PM +0200, Corinna Vinschen wrote:
> >On Aug 14 11:19, Christopher Faylor wrote:
> >> On Fri, Aug 14, 2009 at 04:44:42PM +0200, Corinna Vinschen wrote:
> >> >On Aug 14 10:15, Charles Wilson wrote:
> >> >> Later, when W7 in
On Fri, Aug 14, 2009 at 05:29:04PM +0200, Corinna Vinschen wrote:
>On Aug 14 11:19, Christopher Faylor wrote:
>> On Fri, Aug 14, 2009 at 04:44:42PM +0200, Corinna Vinschen wrote:
>> >On Aug 14 10:15, Charles Wilson wrote:
>> >> Later, when W7 in is more widespread use (e.g. when I have personal
>>
On Aug 14 11:19, Christopher Faylor wrote:
> On Fri, Aug 14, 2009 at 04:44:42PM +0200, Corinna Vinschen wrote:
> >On Aug 14 10:15, Charles Wilson wrote:
> >> Later, when W7 in is more widespread use (e.g. when I have personal
> >> access to it), I'll see if I can improve the situation a bit. Maybe
On Fri, Aug 14, 2009 at 04:44:42PM +0200, Corinna Vinschen wrote:
>On Aug 14 10:15, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>
>> > Oh, ok, sorry about that. I didn't realize there's a urxvt-X and a
>> > urxvtc-X, and accidentally grabbed urxvtc-X when creating the shortcut.
>> >
>> > A
On Aug 14 10:15, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > Oh, ok, sorry about that. I didn't realize there's a urxvt-X and a
> > urxvtc-X, and accidentally grabbed urxvtc-X when creating the shortcut.
> >
> > And yes, it's like you expected. When starting on W7 without run, a
> > c
Corinna Vinschen wrote:
> Oh, ok, sorry about that. I didn't realize there's a urxvt-X and a
> urxvtc-X, and accidentally grabbed urxvtc-X when creating the shortcut.
>
> And yes, it's like you expected. When starting on W7 without run, a
> command window briefly pops up and disappears again.
On Aug 13 21:35, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > Well, there *is* a quick flash console window, but it prints an error
> > message I don't grok:
> >
> > Unable to connect to the rxvt-unicode daemon: No such file or directory
>
> Well, this string only appears in the urxvt
Corinna Vinschen wrote:
> Well, there *is* a quick flash console window, but it prints an error
> message I don't grok:
>
> Unable to connect to the rxvt-unicode daemon: No such file or directory
Well, this string only appears in the urxvtc-X code (the "client" code
for urxvtd-X). If you have
On Aug 12 13:13, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > I can confirm this. It only happens with urxvt-X for some reason.
> > I don't see this for xterm, or xeyes, or xclock.
>
> Me too.
> [...]
> I need another piece of information before deciding how to address this
> issue. If
On 8/12/2009 2:15 PM, Ken Brown wrote:
On 8/12/2009 1:34 PM, Charles Wilson wrote:
Ken Brown wrote:
I'm running XP SP3. To reproduce the problem:
1. Start the X server by using the start menu shortcut (which invokes
run.exe on startxwin.bat).
2. Start emacs by the shortcut above.
3. List the
Ken Brown wrote:
> I'm running XP SP3. To reproduce the problem:
>
> 1. Start the X server by using the start menu shortcut (which invokes
> run.exe on startxwin.bat).
> 2. Start emacs by the shortcut above.
> 3. List the home directory via C-x d [RET].
> 4. Repeatedly press the space bar to scro
Corinna Vinschen wrote:
> I can confirm this. It only happens with urxvt-X for some reason.
> I don't see this for xterm, or xeyes, or xclock.
Me too.
urxvt-X (and urxvtd-X) have their own hide-the-console code, taken from
inetd, as originally written by Corinna.
The core function is hide_cons
On 8/12/2009 9:43 AM, Corinna Vinschen wrote:
On Aug 11 21:40, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Charles Wilson on 8/10/2009 11:51 AM:
The run package provides a simple application to launch console programs
with their console hidden.
I'm now seeing
Cheers Ray.
-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: 12 August 2009 14:44
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] Updated: run-1.1.11-1
On Aug 11 21:40, Eric Blake wrote:
> -BEGIN PGP SIG
On Aug 11 21:40, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Charles Wilson on 8/10/2009 11:51 AM:
> > The run package provides a simple application to launch console programs
> > with their console hidden.
>
> I'm now seeing urxvt-X consume 100% CPU when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Charles Wilson on 8/10/2009 11:51 AM:
> The run package provides a simple application to launch console programs
> with their console hidden.
I'm now seeing urxvt-X consume 100% CPU when it is invoked via /bin/run on
a batch script. Reve
The run package provides a simple application to launch console programs
with their console hidden.
[[ compiled using gcc-3.4.4-999 ]]
CHANGES since run-1.1.10
* New maintainer (Charles Wilson took over from Alexander Gottwald)
* Updated build machinery
* Added patch
66 matches
Mail list logo
