Re: 'run xterm' fails to open a window
On Fri, Nov 20, 2009 at 4:25 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 13/11/2009 03:14, Ken Brown wrote: On 11/12/2009 3:17 PM, Jon TURNEY wrote: On 10/11/2009 23:44, Mike Ayers wrote:] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mikeC:\cygwin\bin\run.exe -p /usr/bin sh -c gvim/dev/null 21 C:\mike [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion When I start xterm via run, this message apparently has nowhere to go and the xterm process is blocked. Mike's workaround (with 'gvim' replaced by 'xterm') solves the problem, as he said. Is this a bug in run? It does kind of look like some problem with run, but not a universal one, 'run xterm' has been working as expected for me, even when it has to output something. Experimenting a bit, this seems to be related to having CYWIN=tty set in the windows environment. If I remove that, I can reproduce the problem you see. I really don't understand the invisible console stuff well enough to attempt a fix, though... Ok thanks, yes CYGWIN=tty does fix the issue! many many thanks! JLM -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
On 13/11/2009 03:14, Ken Brown wrote: On 11/12/2009 3:17 PM, Jon TURNEY wrote: On 10/11/2009 23:44, Mike Ayers wrote:] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mikeC:\cygwin\bin\run.exe -p /usr/bin sh -c gvim/dev/null 21 C:\mike [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion When I start xterm via run, this message apparently has nowhere to go and the xterm process is blocked. Mike's workaround (with 'gvim' replaced by 'xterm') solves the problem, as he said. Is this a bug in run? It does kind of look like some problem with run, but not a universal one, 'run xterm' has been working as expected for me, even when it has to output something. Experimenting a bit, this seems to be related to having CYWIN=tty set in the windows environment. If I remove that, I can reproduce the problem you see. I really don't understand the invisible console stuff well enough to attempt a fix, though... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
thanks for the reply I tested doing c:\Cygwin\bin\run.exe sh -c env|grep DISP /cygdrive/c/log I get the expected value : DISPLAY=:0.0 C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /cygdrive/c/log 21 do diplay waring in the log but does make the window appears in fact it seems that because gvim do output some error string it is stopped by run.exe so as said in next reply C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /dev/null 21 is a workaround thanks JLM On Tue, Nov 10, 2009 at 7:03 AM, Linda Walsh cyg...@tlinx.org wrote: jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
the workaround isn't sufficient installing the font don't help setting the LANG=C don't help but in gvim.bat C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim '%*'/dev/null 21 don't work all the time 1)if I run it in a cmd.com : gvim.bat c:\some\path\to.file it's working 2)if I do open with in explorer, this don't work, after investigation it appears that %* in this case is replaced by c:\some\path\to.file ie C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim 'c:\some\path\to.file'/dev/null 21 (note that there is double quote inside single quote) removing the single quote cause the \ to be escaped and then gvim try to open c:omeatho.file. please can someone give a fix to run.exe so that the process is run with stdout and stderr redirected to /dev/null? thanks JLM On Mon, Nov 16, 2009 at 5:04 PM, jean-luc malet jeanluc.ma...@gmail.com wrote: thanks for the reply I tested doing c:\Cygwin\bin\run.exe sh -c env|grep DISP /cygdrive/c/log I get the expected value : DISPLAY=:0.0 C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /cygdrive/c/log 21 do diplay waring in the log but does make the window appears in fact it seems that because gvim do output some error string it is stopped by run.exe so as said in next reply C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /dev/null 21 is a workaround thanks JLM On Tue, Nov 10, 2009 at 7:03 AM, Linda Walsh cyg...@tlinx.org wrote: jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm --
Re: 'run xterm' fails to open a window
On 11/12/2009 10:14 PM, Ken Brown wrote: Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion [...] It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Never mind. I found the answer in a different thread: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00085.html The workaround is to install the font-isas-misc, font-jis-misc, and font-daewoo-misc packages. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
On 10/11/2009 23:44, Mike Ayers wrote: On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mikeC:\cygwin\bin\run.exe -p /usr/bin sh -c gvim/dev/null 21 C:\mike [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Also, the suggestions that this has something to do with DISPLAY not being set correctly seem a little unlikely. If gvim or any other X application isn't able to determine which display to use, it should exit with an error, not hang around -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: 'run xterm' fails to open a window
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Jon TURNEY Wait, are you saying that the process that run starts is blocked if it tries to output anything? That is what I am experiencing. Also, the suggestions that this has something to do with DISPLAY not being set correctly seem a little unlikely. If gvim or any other X application isn't able to determine which display to use, it should exit with an error, not hang around I agree. I think DISPLAY is a red herring. Not having the display set can cause programs which exit without output, not hang around. HTH, Mike
Re: 'run xterm' fails to open a window
On 11/12/2009 3:17 PM, Jon TURNEY wrote: On 10/11/2009 23:44, Mike Ayers wrote: On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mikeC:\cygwin\bin\run.exe -p /usr/bin sh -c gvim/dev/null 21 C:\mike [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion When I start xterm via run, this message apparently has nowhere to go and the xterm process is blocked. Mike's workaround (with 'gvim' replaced by 'xterm') solves the problem, as he said. Is this a bug in run? It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: 'run xterm' fails to open a window
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mikeC:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /dev/null 21 C:\mike [/SNIP] HTH, Mike
Re: 'run xterm' fails to open a window
Mike Ayers wrote: [...] Apparently, run.exe is not providing stdout/stderr to dump to. Is that by chance due to the fact that run.exe is compiled with -mwindows, i.e. as GUI? And am I the only one for whom this has further consequences? E.g. in a Windows command prompt or a non-X11 cygwin-console, the command run sleep -wait 5 does *not* wait for the sleep to terminate. Moreover run false -wait does *not* set %errorlevel% to 1. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
run.exe and startxwin.bat [was: 'run xterm' fails to open a window]
Mike Ayers wrote: From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Lothar Brendel Sent: Tuesday, November 10, 2009 4:52 PM E.g. in a Windows command prompt or a non-X11 cygwin-console, the command run sleep -wait 5 does *not* wait for the sleep to terminate. Moreover run false -wait does *not* set %errorlevel% to 1. Why are you using run for these? I normally don't. It was what I boiled down the non-functioning line %RUN% checkX -wait -d %DISPLAY% -t 12 in startxwin.bat (from xinit-1.1.1-6.tar.bz2) to. Like that, the -wait has no effect and a non-running X-server isn't reflected in %errorlevel%, either. And (of course) I can confirm the correct behaviour when using sh.exe instead of run.exe. Which brings us to the question of using run.exe in startxwin.bat. I don't see the point of hoping for a windowless console there, since a BAT-script always opens a window anyway (even when starting with @echo off and outputting nothing). Hence, wouldn't be sh.exe instead of run.exe the right thing for startxwin.bat? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... thanks and regards JLM On Fri, Nov 6, 2009 at 7:40 PM, Mike Ayers mike_ay...@tvworks.com wrote: From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of jean-luc malet Sent: Thursday, November 05, 2009 6:18 AM gvim.bat : c:\cygwin\bin\run -p /bin gvim Try: c:\cygwin\bin\run -p /bin:/usr/X11R6/bin gvim HTH, Mike -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
I would suggest you run the native version of 'gvim' instead of the cygwin 'gvim' unless you know you need something that the 'X' version provides. You can download the native gvim from the vim website. The native version can use the SAME config files as the cygwin version (i.e. it works equally well with LF line endings as it does CRLF line endings). It handles / or \ as path separators. I believe. BUT, one caveat, I have my Cygwin installed in C:\ not C:\cygwin, and my drive prefix is / not 'cygdrive/' This means all my dos paths and cygwin paths are *equal*. So from any directory, if I type in 'vi xxx', I get the cygwin based 'vi' editor, but if I want a gui, I can type in 'gvim xxx' and I will get the native-windows based gui. Just make sure you add /prog/vim/ to your path (or wherever you install vim programs). It's faster and doesn't need a running xserver. I do use the X-version of gvim, but only when editing a file on a remote machine. That said, the process of getting the 'X' version of gvim is straightforward. Start from debugging the launching of it in 'cmd.exe' -- that's like calling it from 'run'. which is similar to how explorer will run it. Also, if you use :0 for your output, be sure to put it in quotes. DISPLAY=:0 isn't safe unless it is quotes : DISPLAY=:0 DISPLAY=:0 will go through a unix socket to talk to your Xserver. In 'xhost', it shows up as LOCAL:, whereas internet addresses show up as INET:localhost (entry for localhost:0). jean-luc malet wrote: Hi! I have the same kind of issue but with gvim however it does work with xterm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
'run xterm' fails to open a window
Hi, 2009/11/3 Linda Walsh cyg...@tlinx.org: 1) to Florent Fievee, (you don't need to answer if you have no good reason, but if you do, I'm curious as to your reasoning) -- Why did you copy Ken's complete note as into your response, when you simply has to say me too? I simply clicked on reply button of my webmail. I will not do it again ;-) 2) to both Florent and Ken? In addition to Gery Herbozo Jimenez's response and question to you, ( Have you tried just starting the XWin server first and the the xterm? it looks like the X server doesn't recognize that line command. ), a) Have you tried starting 'xterm' without 'run' ? Yes, it works without problem but a cmd window remain and that is annoying. To explain exactly my situation, I have a Windows cmd script which try to launch a bash script. --- rxvtwin.cmd -- @echo on SET DISPLAY=127.0.0.1:0.0 if defined CYGWIN_ROOT goto :OK set CYGWIN_ROOT=%~dp0 :OK SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=%CYGWIN_ROOT%\bin;%PATH% %RUN% %CYGWIN_ROOT%\bin\bash /usr/local/bin/rxvtwin.sh %* --- I call it in windows shortcut with a u...@host as parameter and it launch a rxvt terminal with a ssh session to the host and background color depending on host. If instead of %RUN% %CYGWIN_ROOT%\bin\bash /usr/local/bin/rxvtwin.sh %* I launch %CYGWIN_ROOT%\bin\bash /usr/local/bin/rxvtwin.sh %*, it works. So it seems to be really run which has an issue. b) I see you have started 'Xwin'. Do either of you know what display 'XWin' started itself on? If you specified no value, it probably created the display :0.0. Yes my server is running on display 0.0 and I specify it in DISPLAY environment variable. (I specified it in both bash and cmd script since I don't know if environment is inherited by bash process when I run it) Your cygwin path\bin\bash.exe -c 'DISPLAY=:0 xterm' for cygwin path='C:\cygwin': C:\cygwin\bin\bash.exe -c 'DISPLAY=:0 xterm' or C:\cygwin\bash\bash.exe -c 'xterm -display :0' for cygwin path= 'C:\': (my value) C:\bin\bash.exe -c 'DISPLAY=:0 xterm' or C:\bash\bash.exe -c 'xterm -display :0' The above two commands work on WinXP and Vista under the 1.5.x series of Cygwin. It don't work as I expected since what I have explained before. But I have a little track : My office has given me a new computer and with the old I had no problem with the same scripts, the difference between the two is that the old one was Windows XP 32bits and the new one is Windows XP 64 bits. I tried first with cygwin 1.5 and I installed also cygwin 1.7 (I have the same problem in both installation). Best Regards, Florent Fievez -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: 'run xterm' fails to open a window
Have you tried just starting the XWin server first and the the xterm? it looks like the X server doesn't recognize that line command. Date: Tue, 3 Nov 2009 09:27:23 -0500 From: kbr...@cornell.edu To: cygwin-xfree@cygwin.com Subject: 'run xterm' fails to open a window I don't know if this is a problem with run, or xterm, or something else. If I start the X server and then type 'run xterm' in an xterm window, the xterm process starts but does not open a window. Here's what 'ps' shows before and after 'run xterm': $ ps PID PPID PGID WINPID TTY UID STIME COMMAND 780 1 780 780 ? 1006 08:50:17 /usr/bin/mintty I 2932 780 2932 1480 0 1006 08:50:17 /usr/bin/bash 384 1 1708 2740 0 1006 08:50:32 /usr/bin/XWin 2648 384 2648 3064 ? 1006 08:51:07 /usr/bin/xterm 528 2648 528 3016 1 1006 08:51:11 /usr/bin/bash 3144 528 3144 1464 1 1006 09:05:28 /usr/bin/ps $ run xterm $ ps PID PPID PGID WINPID TTY UID STIME COMMAND 780 1 780 780 ? 1006 08:50:17 /usr/bin/mintty I 2932 780 2932 1480 0 1006 08:50:17 /usr/bin/bash 384 1 1708 2740 0 1006 08:50:32 /usr/bin/XWin 2648 384 2648 3064 ? 1006 08:51:07 /usr/bin/xterm 528 2648 528 3016 1 1006 08:51:11 /usr/bin/bash 3452 1 3452 3452 con 1006 09:05:57 /usr/bin/xterm 4088 528 4088 3664 1 1006 09:06:01 /usr/bin/ps Obviously I have no good reason to want to start an xterm via 'run xterm' in an xterm window, but this issue is causing problems in a script I'm writing. [Briefly, I have a desktop shortcut with target '\path\to\run.exe bash -c foo.sh'. The script foo.sh calls xterm, which starts with no visible window, exactly as above.] I've attached cygcheck output and the XWin log. Ken _ Date una vuelta por Sietes y conoce el pueblo de los expertos en Windows 7 http://www.sietesunpueblodeexpertos.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
Florent Fievez wrote:
I've exactly the same issue, so if you find a solution, please post it ! ;-)
2009/11/3 Ken Brown kbr...@cornell.edu wrote::
'run xterm' fails to pen a window:
I don't know if this is a problem with run, or xterm, or
something else.
...
Obviously I have no good reason to want to start an xterm via 'run xterm' in
an xterm window, but this issue is causing problems in a script I'm writing.
[Briefly, I have a desktop shortcut with target '\path\to\run.exe bash -c
foo.sh'. The script foo.sh calls xterm, which starts with no visible
window, exactly as above.]
---
I have two responses, 1, mostly to Florent Fieves, the other to both
Florent, and Ken Brown who wrote that he also has the problem
1) to Florent Fievee, (you don't need to answer if you have no good
reason, but if you do, I'm curious as to your reasoning) --
Why did you copy Ken's complete note as into your response, when you
simply has to say me too?
2) to both Florent and Ken?
In addition to Gery Herbozo Jimenez's response and question to you,
( Have you tried just starting the XWin server first and the the
xterm? it looks like the X server doesn't recognize that line
command. ),
a) Have you tried starting 'xterm' without 'run' ?
b) I see you have started 'Xwin'. Do either of you know what display
'XWin' started itself on?
If you specified no value, it probably created the display :0.0.
If you then open a 'client' program that needs to attach to your
Xwin display, you need to ensure that the new client knows what
X display your client connects to (usually, :0.0). A well
behaved X client won't make assumptions about what display to use.
If you were running entirely under *nix, any X clients you opened
afterwards would use the the display passed in the Environment via
'DISPLAY'. However, both of you appear to be starting Xwin with
no preset value of 'DISPLAY' AND passing NO (of
DISPLAY) to the 'X client' program, 'xterm', in order to tell it
what 'X display' to use.
You both appear to be doing the same thing. You both start an Xserver
in background (which is normal and what I do as well). You then appear
to be starting a client ('xterm'), in a separate session (an empty
Xsession, with no display). In order for an X client to display to
an Xserver, it needs to know what display to open it's output window
on.
Suggestions:
1) Don't use the cygwin command 'run.exe' unless you are
calling Windows programs.
2) Explicitly tell xterm what display to use. Set the value of
the environment var 'DISPLAY' before you all xterm.
Ex. Using the Windows 'Run' command (from the start menu, using the
builtin Windows 'Run' option on the start menu):
Your cygwin path\bin\bash.exe -c 'DISPLAY=:0 xterm'
for cygwin path='C:\cygwin':
C:\cygwin\bin\bash.exe -c 'DISPLAY=:0 xterm'
or
C:\cygwin\bash\bash.exe -c 'xterm -display :0'
for cygwin path= 'C:\': (my value)
C:\bin\bash.exe -c 'DISPLAY=:0 xterm'
or
C:\bash\bash.exe -c 'xterm -display :0'
The above two commands work on WinXP and Vista under the 1.5.x series
of Cygwin.
Linda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
RE: 'run xterm' fails to open a window
4af080a4.7050...@tlinx.org
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Hi Linda=2C
=20
Thanks for your answer and explanation. I just press the Xserver icon and t=
hen the xterm (most of the time) appears. If not=2C I press the xterm icon.=
Simple like that. I don't write run or something like that in anycase.
=20
Hope this helps=2C
=20
Cheers=2C=20
Gery
=20
Date: Tue=2C 3 Nov 2009 11:12:36 -0800
From: cyg...@tlinx.org
To: mail...@fievel.be
CC: cygwin-xf...@cygwin.com=3b gameji...@hotmail.com
Subject: Re: 'run xterm' fails to open a window
=20
Florent Fievez wrote:
I've exactly the same issue=2C so if you find a solution=2C please post =
it ! =3B-)=20
2009/11/3 Ken Brown kbr...@cornell.edu wrote::
'run xterm' fails to pen a window:
I don't know if this is a problem with run=2C or xterm=2C or=20
something else.=20
...
Obviously I have no good reason to want to start an xterm via 'run xter=
m' in
an xterm window=2C but this issue is causing problems in a script I'm w=
riting.
[Briefly=2C I have a desktop shortcut with target '\path\to\run.exe bas=
h -c
foo.sh'. The script foo.sh calls xterm=2C which starts with no visible
window=2C exactly as above.]
---
=20
I have two responses=2C 1=2C mostly to Florent Fieves=2C the other to bot=
h
Florent=2C and Ken Brown who wrote that he also has the problem=20
=20
1) to Florent Fievee=2C (you don't need to answer if you have no good
reason=2C but if you do=2C I'm curious as to your reasoning) --=20
=20
Why did you copy Ken's complete note as into your response=2C when you
simply has to say me too?
=20
=20
2) to both Florent and Ken?
=20
In addition to Gery Herbozo Jimenez's response and question to you=2C
( Have you tried just starting the XWin server first and the the
xterm? it looks like the X server doesn't recognize that line
command. )=2C=20
=20
a) Have you tried starting 'xterm' without 'run' ?=20
=20
b) I see you have started 'Xwin'. Do either of you know what display
'XWin' started itself on?=20
=20
If you specified no value=2C it probably created the display :0.0.
=20
If you then open a 'client' program that needs to attach to your
Xwin display=2C you need to ensure that the new client knows what
X display your client connects to (usually=2C :0.0). A well
behaved X client won't make assumptions about what display to use.
=20
If you were running entirely under *nix=2C any X clients you opened
afterwards would use the the display passed in the Environment via
'DISPLAY'. However=2C both of you appear to be starting Xwin with
no preset value of 'DISPLAY' AND passingNO (of=20
DISPLAY) to the 'X client' program=2C 'xterm'=2C in order to tell it
what 'X display' to use.
=20
=20
You both appear to be doing the same thing. You both start an Xserver
in background (which is normal and what I do as well). You then appear
to be starting a client ('xterm')=2C in a separate session (an empty
Xsession=2C with no display). In order for an X client to display to=20
an Xserver=2C it needs to know what display to open it's output window
on.
=20
Suggestions:=20
1) Don't use the cygwin command 'run.exe' unless you are
calling Windows programs.=20
=20
2) Explicitly tell xterm what display to use. Set the value of
the environment var 'DISPLAY' before you all xterm.
=20
Ex. Using the Windows 'Run' command (from the start menu=2C using the
builtin Windows 'Run' option on the start menu):
=20
Your cygwin path\bin\bash.exe -c 'DISPLAY=3D:0 xterm'
=20
for cygwin path=3D'C:\cygwin':
=20
C:\cygwin\bin\bash.exe -c 'DISPLAY=3D:0 xterm'
or
C:\cygwin\bash\bash.exe -c 'xterm -display :0'=20
=20
for cygwin path=3D 'C:\': (my value)
=20
C:\bin\bash.exe -c 'DISPLAY=3D:0 xterm'
=20
or
=20
C:\bash\bash.exe -c 'xterm -display :0'=20
=20
=20
The above two commands work on WinXP and Vista under the 1.5.x series
of Cygwin.=20
=20
Linda
=20
_
Deja que Sietes te ense=F1e todo los secretos de Windows
http://www.sietesunpueblodeexpertos.com/=
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
Gery Herbozo Jimenez wrote: Thanks for your answer and explanation. I just press the Xserver icon and t hen the xterm (most of the time) appears. If not, I press the xterm icon. Simple like that. I don't write run or something like that in anycase. --- Oddly enough, I find the menu items less reliable (by grouping): Under cygwin: - MinTTY, rxvt-unicode-xS, rxvt-unicode-xC: work - rxvt-x, rxvt-native (*pseudo* work: come up w/poopy doublewide-font) Under cygwin/cygwin-X - oclock works, but not xclock. - rxvt works (perversely, w/double-wide chars) - none of the rest work Under cygwin/cygwin-X/Toys: - glxgears, xeyes, xlogo, ico--- all work - xgc doesn't work from menu (but does from Bash). Under cygwin/cygwin-x/tools: - only xev and xrefresh work - idle gives a path-not-found message (may not be installed) - the rest give no output, but start a process (that sits in background until I kill it). Under cygwin-xgames, texteroids brings up a window, then immediately exits. From bash, I see the error message: | %% DPS Client Library Warning: | Auto-launching DPS NX agent. | %% DPS Client Library Warning: | FAILED to auto-launch: | dpsnx.agent | | texteroids: DPS is not available. | You need an X server with the DPS extension, or a DPS NX agent. Hope this helps. In some way. It lets me know that my reasoning for doing workarounds, that I implemented years ago, were done for good reason. The default menu items don't work reliably in some environments (like mine). It is interesting to check out things I didn't even know I had installed! :-) I don't regard any of the above that don't work as 'bugs', as I don't know what some of them are *supposed* to do, and it could easily be I have something interfering in my path. I'd have to go through each menu item in its properties and figure out why they didn't work before I'd call them a bug -- some may be left over menu items that didn't get deleted properly' when an app was moved or uninstalled. I see at least a few, in my setup, that still reference /usr/X11R6/bin for executables, when their executable is now under /usr/bin (though some executables are under my /usr/X11R6/bin -- maybe alien binaries; again, I'd only report something as a bug if I was pretty sure it wasn't unique to my setup; I do too many non-standard things; :-) ). I don't know how the shortcut got left around, so I certainly wouldn't report it as bug or problem to the cygwin list. Another potential source of problem I found today, while playing around. I had the setting of LANG set to incorrect value 'en_US.utf8', but it should be 'en_US.utf-8' for some applications that 'care'. :-) Same could could for CTYPE or some of the LC prefixed vars -- if they are set incorrectly it might prevent one of the X utils opening properly when called by run. To set those values, you need to alter them in 'System properties', Advanced - Environment Variables. I have LANG in my System variables section, but DISPLAY, I made a 'User' variable. I see LANG being SYSTEM wide. I see DISPLAY as only being valid with my login as it's only when I login that the Xserver is started (I autostart it via a shortcut in my Programs-Startup Menu group). Linda Yakinalotski :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
