Re: Auto hidden taskbar stays hidden
If you are in WinXP and, I think, past versions of windows, there is an option on the task-bar properties page right under the Auto-hide checkbox to Keep taskbar on top of other windows. That must also be checked to keep the taskbar's single-hidden line on top, so it can catch your mouse movement. Might also try pressing the Windows key to see if the menu pops up (should also bring up task bar) or ctrl-ESC (same as single press of windows key, but can't be used as a modal- or shifted- Windows key). Other than that, it could be an option, bug or feature for those who might want a completely X desktop, I suppose;^). Linda Thomas Gilgin wrote: Hi list, I use an auto hiding taskbar. If an application, e.g. xterm or a native windows application is maximized, the task bar does not appear if the mouse pointer is moved to the border of the desktop. If no window is maximized, it works as expected. Is this a bug or my fault? :-) Best regards, Thomas Gilgin -- 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/ -- 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: Problems with X surfaced recently
Larry Hall (Cygwin) wrote: (thank you for your responses...) Cygwin-X questions go to the cygwin-xfree list. --- I thought the lists were being merged because there was next to zero traffic on the X-cygwin list? Did that plan fall by the wayside? Besides, I wasn't sure if there was some negative interaction being caused by the setup problems. Did you miss this FAQ? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-i-cant-type-anything Well, I didn't get the Change Notification, if that's what you mean...:-) I have read the FAQ's, but I don't re-read them with each release. I'm pretty certain, I wouldn't notice a few new paragraphs difference in a 90k document... I normally don't use the start-menu as it suggests, as I don't use the same XWin start args nor start an xterm when starting X. Or this one? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-where-are-my-fonts --- I think I'll go look more closely at the FAQ. :-) The keyboard is functioning, now, on another remote app (make xconfig -- which is what started this 'detour'). However, an Xterm running on a remote (linux) system fails when trying to display to my cygwin-OS system with a similar font problem, so I reckon some font paths have changed or moved. Sigh. Thanks for following the problem reporting protocol concerning cygcheck output. :-) --- I try to improve...just a bit slow sometimes or not sure when a specific rule applies. I'm overly concerned (paranoid?) with dumping a large quantity of script-produced data, since I don't know if there is something in the dump that might create a security leak and I know the email list is archived and publicly searchable forever. ;^/ -- 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/
Bug in startXwin.bat
The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix -- 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: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? -- 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: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. Larry -- The reason I changed forums was that the TOPIC/SUBJECT changed. It went from my finding a bug in the Cygwin Xserver's startxwin.bat script (something appropriate for the cygwin-xfree list) to a more general question of how one would solve the problem of finding the cygwin prefix in a windows batchfile. Just because you can't answer the question without circular logic is no reason to get upset. -- 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: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. Larry -- The reason I changed forums was that the TOPIC/SUBJECT changed. This is perfectly reasonable, except you kept both threads running. Not exactly. They were different posts -- I realized it was a more general topic after first responding to the xfree. It went from my finding a bug in the Cygwin Xserver's startxwin.bat script (something appropriate for the cygwin-xfree list) to a more general question of how one would solve the problem of finding the cygwin prefix in a windows batchfile. Actually, that's not the question you asked, though I'll concede that this is what you meant to ask. And I answered that on the main list. For completeness, I'll paraphrase it here - there's no good way. AH HAH! Thank-you. My original intent was simply to report a bug in the Cygwin-X startup script startxwin.bat that you told me (indirectly via the FAQ) to use. My first idea was to use mount -p as you suggest. However, I immediately realized that mount wouldn't be available if you were not already in the Cygwin environment. Just because you can't answer the question without circular logic is no reason to get upset. While other statements of yours have been understandable, even if they were in error, this one makes no sense so I won't respond to it. --- Probably somewhat a case of projection... ;^ -- 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/
Why is remote client being rejected? AUDIT: XWin: client 4 rejected from IP 192.168.3.3
Yes I've read the FAQ -- it doesn't help. Is says: The problem is most likely a wrong DNS (Network name resolution). Make sure your windows host has a hostname which is valid from linux too and an IP address which linux can resolve to that hostname. --- What DNS resolution? If you add a line 192.168.26.1 myhost to /etc/hosts on the XDMCP server with the IP address and the hostname of your windows host the name resolution should work. XDMCP server? I'm not trying to connect to an XDMP server. I'm trying to open 'xosview' on a remote host with DISPLAY=mycywin-window-machine:0.0 (or machine:0), neither work. Yes I export the variable on the remote machine or I wouldn't be getting the rejected message in my local cygwin XWin /var/log/XWin.0.log file. It =works= if I let it connect through my 'ssh' connection but that's really connecting back to ssh on the cygwin machine and connecting, AFAIK, via the local socket or local host. I wanted to try connecting NOT through my ssh connection so I could close the ssh connection and have the remote xosview continue running. Thanks for ideas... 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: Why is remote client being rejected? AUDIT: XWin: client 4 rejected from IP 192.168.3.3
j...@asyn.org wrote: Have you added the client to your X server's acl? See xhost(1) --- I thought I'd turned off access checking. I forgot I had to redo my script when there was a major X-server upgrade, a few months ago -- Not something I 'normally use'... (Am pretty safe, regardless, as I'm doing this on an isolated, wired, subnet in my house, so I feel pretty safe unless my beagle orders a computer. Also, running your X client in the background does not disconnect it from the terminal from which you launched it. If you close the terminal, the client app will die. Yeah, know about that one: (xosview) saves it from the HUP's when the window closes... THANKS! 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: X11R7.5 fontcache..
Does this mean it is a 'beta' or test version? If it is a released version, will it be made available for the released version of cygwin (1.5). I've no idea when cygwin will release 1.7 as being 'ready'... How difficult would it be to turn on compiling in of the 'font-cache' extension? I use fonts (oddly enough), and use the xfs. I believe the font-cache allows faster performance for networked fonts? Yaakov (Cygwin/X) wrote: Cygwin/X has been updated to X.Org X11R7.5 (for Cygwin 1.7 only). -- 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: Problem installing cygwin/X on vista sp2 64bit
Massimo Giovannini wrote:
Hi,
I have always installed and used cygwinX on my windows Xp
machines without any problem.
I have been trying to install on my new Vista 64 bit laptop
and I cannot figure out what is going wrong.
---
W e l c o m e t o V i s t a !
:-)
I've been going through similar pains playing with a still not fully
functional Vista machine (still awaiting a Win7 upgrade as well).
Even though you got the standalone X-server to work, FWIW, on
Vista, you could also be running into permission problems even as
Admin. Many files and directories don't have write permission enabled
for Admin. To enable them you have to 'get violent' with Vista and
reclaim directories you want write access to by taking over their
ownership and then making it so you have r/w access. If you do this,
take care to note the original owner and/or accesses to make sure that
any group/ID that had access before ('TrustedInstaller', 'SYSTEM') also
has the same (usually full control) access after you take ownership.
The prompt in your cygwin window being 'broken' is possibly a symptom
of that. By default, I found that I couldn't add files to my root
directory (a good thing, actually, too many apps still try to install
stuff there, and a default no files prevents accidental clutter).
Just thought I'd add an addendum, though looks like Larry gave you
the exact solution you needed.
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
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
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/
META CONTENT: posting format redux: education of a welcome, new community member...?
Florent Fievez wrote: 2009/11/3 Linda Walsh me'em...@me'dom: ^^^ -- another no no**(see bottom) [curious] Why did you copy [the previous,] complete note into your response, when [all you said was] me too? I simply clicked on reply button of my webmail. I will not do it again ;-) --- The point was not whether you hit reply, but whether or not you chose to edit down the part you included to some minimal subset of the message so as not to fill the rest of anyone's screen with unnecessary characters. Some people (call them group A) use text-only readers that display the whole message from top to bottom that scrolls your response off the screen if you fill your message with a copy of a long included response. As a result, they have to redisplay your message with paging enabled, just to see a 1-liner that is placed at the top of the message (call that Style-A). Other people (call them group B) using Graphical-readers(GUI's) to read email only see the first page of a long email, so when someone includes the whole message and puts a 1-liner at the end (call that style B), have to manually scroll through a bunch of text they've already read in previous posts, just to see a one liner. Note: Style-A is sometimes called 'top-posting', and Style-B is sometimes called 'bottom-posting'. When someone is using a GUI, and reads a 'Style-B' message, they have to slowly scroll through your message, either using the mouse or using some page-down type character. That can be a tedious and error-prone process In both cases it requires more work to read your message which was simply a me too message that didn't require inclusion of the entire previous message. So some people get 'irritated' at having to scroll up or page through repeated text just to get to a me too response. This is even more of a problem for people who have disabilities -- blind people might have problems reading through tons of repeated text just to get to important stuff, so its important for you to pare down the extraneous parts to make it easier in any event. People with motion disabilities (including people with RSI type problem (Carpal tunnel, Ulnar 'tunnel', or spinal problems) may have problems with the extra motions required to read your text. So, in generally, it's just a good idea to trim down included text to some minimal context that is needed to make your message make sense -- which is, nearly always, something that is both, considerably less than the full message, but will also fit on 1 screen, with your message, of those in group-A and in group-B -- thus making both happy, though, I believe Style-A (AKA top-posing), as you did, would best serve those using screen-readers -- which work with GUI's but not usually text-style windows. Note -- you didn't do anything *wrong* -- I'm just letting you know the problems that other people have raised about posting styles in the past, so you can be aware, and be conscious about your posting style. We certainly don't want any *unconscious postings*! :-) (been there, done that, got no T-shirt -- just negative karma points). Hopefully I won't get flamed for this, but I'm cross-posting this to the cygwin main list, as well, where this issue comes up on some periodic basis, with the hope that my suggestions will be considered: Style-A (AKA top-posting) is easier on people with disabilities, but excessively quoting old text such that the new content is scrolled off a screen is also annoying and wasteful. For those in Group-B, if they are trying to be thorough and make sure you had no further comments interspersed with the content below, they'll still be forced to page through pages of repeated text). I'll respond to the rest of your note separately on the appropriate list. Linda ** -- it's also considered a no-no, to include people's actual email address when responding: use their name instead or at least heavily obfuscate their email addr, since these emails are archived on publicly searchable websites and spammers skim these archives to look for email addresses to send spam to. I can vouch for getting a considerable amount of spam sent my list-dedicated email accounts. -- 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: release scheduling, cygwin 1.7 et al (was Re: X11R7.5 fontcache..)
* Yaakov (Cygwin/X) wrote: http://cygwin.com/acronyms/#RSN :-) ** LW wrote: --I don't suppose you could express that in ISO format? :-) Larry Hall wrote: Since you've asked this on multiple lists, I'm going to assume this is more than just a humorous comment that you don't expect an answer to. Posting this as a reply on cygwin would have been more appropriate, as there, it was obvious, I was *repeating* the question, (I mentioned it came up on this list), and it was there that I was *probing*, to see if a more firm day had been given that I had missed. Cygwin 1.7 will be released as soon as it's ready. So I've heard. There is no specific date at this time. --- Same as before. So I haven't missed any news and there is still no timeframe (could still be a year away) for release... firm dates are one thing, but we are hoping before Xmas, or Beltane (May Day) would give an idea. That said, I very well know the unpredictable nature of SW development. How can one give a real schedule about something that has never been done before? Managers have pushed the moniker 'software engineering' onto the field -- as though software is something that can be engineered and manufactured like off-the-shell nuts and bolts. That does the field a great disservice. As writing software is all about creativity. It's not about creating the nuts and bolts, but how they go together -- just like painting is not about the paint, it's about how it goes onto the medium. Sure you can give estimates, but reality is they are only best guesses and any number of things can come up to alter them. This was known as far back as 1985. See good paper at: http://dspace.mit.edu/handle/1721.1/48174?show=full Says basically, even the act of coming up with a schedule can [adversely] affect the outcome of not creating one. The compare it to the 'Heisenberg Uncertainty Principle' But even with such knowledge at your disposal, you'll still run into Dilbertian manager types who live in a fantasy world, where, by force of will, they believe they can force a product into existence on their schedule. :^) However, I am not the manager type -- I'm not ruthless enough. That's not a reason not to use it however, if you prefer. And if you need something that's only on 1.7, this is a good time to try it out. And since you can install 1.7 beside 1.5 if you like, your risk of borking your Cygwin installation is pretty minimal. --- I saw support for dual installations in a recent announcement on Cygwin's main list. I've also seen quite a few problems reported against 1.7 in the compatibility department, but I realize that gives no indication of the number of users who don't have problems. The announced wasn't clear if the dual installation support was backwards compatible to 1.5. My history with cygwin goes back a bit, to, when having more than one cygwin install on your disk at the same time was grounds for being drawn and quartered if you reported any problem in such a setup. You know how the cygwin-standard team can be...any excuse for flaying a user provides them joy (in their 'we take pride in our meaness' way). :-) Maybe when I'm not swamped w/other probs... Thanks for the ~informative~ response. ;^) -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/
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: vnc btter than X...?
Michael Breuer wrote: That was probably pushing things anyway as the proper way is to run VNC remotely, not in a remote X session... but I figured I'd try to break it. --- Why is VNC more proper than X? I haven't been able to get VNC to work, but X runs wonderfully. What am I missing? :-) If it's really an improvement, I might spend some more time trying to get it to work... FYI, I'm connecting over an internal 1Gb ethernet with no need for encryption (it's an isolated, internal subnet). So would vnc any advantage? Sorta tangential to the original discussion, but thought I'd ask... thanks, 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/
remote desktop
I'm trying to get a remote desktop to come up, but am not sure what's required on the remote end. Locally, I've been trying 'Xwin -query hostname Either they come up with no login screen, or in one case an error where it said: winProcEstablishConnection - Xdmcp, waiting to start clipboard client until 4th call... winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winGetDisplay: DISPLAY=:0.0 winClipboardProc - DISPLAY=:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winProcQueryTree - Hello winProcQueryTree - Clipboard client already launched, returning. winClipboardIOErrorHandler! winClipboardProc - setjmp returned for IO Error Handler. winDeinitMultiWindowWM - Noting shutdown in progress --- Is there something I'm missing or need to setup on my remote clients? They are various levels of suse boxen, and claim to have 'xdm' enabled via their chkconfig -- but I don't know if they are configured properly. Think was, is that I tried this before, and it just worked, but after some recent updates, it stopped working. I guess I just got lucky with it working before? It may be there's too little to go on here, and I just need to start from scratch, and try to figure out how XDM works from the man page, but it's odd that it was setup to 'work', but just seems to have randomly broke as I wasn't trying to change any configuration related to xdm on the remote machines...*sigh*. thanks if anyone sees any overt problems or knows any common ones w/suse... 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: X11R7.5 and C.UTF-8
Ken Brown wrote: On 10/28/2009 6:07 PM, Andy Koppe wrote: 2009/10/28 Ken Brown: Maybe my terminology is wrong. But if you start mintty with no .minttyrc and with LANG unset, mintty will set LANG=C.UTF-8. Yep. That's primarily for emacs' benefit, which parses the locale env variables itself instead of using setlocale(LC_CTYPE, ), thereby missing out on Cygwin's default locale. Andy, I've sent a report about this to the emacs-devel list (http://lists.gnu.org/archive/html/emacs-devel/2009-11/threads.html#01216). But I don't have a good understanding of locale issues. Could you take a look and see if what I said is accurate or if more should be said? C.UTF_8 doesn't exist. mintty is broken. Might want to try 'Console' nstead of using mintty. Not perfect either, but fewer compatibility problems that I've noticed. Examples of valid LANG values: C, ca_FR, en_US, fr_FR, it_IT, nl_NL, wa...@euro You can't have C and UTF-8, because C means no encoding (default). UTF-8 IS an encoding, so they are mutually exclusive. I don't know under what circumstances C might imply UTF-8. If the definition of C changes? It might be easier than changing c (as used in physics). My understanding of locale issues is also limited and subject to change or re-education... :-) -- 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: xterm doesn't open on start
Timares, Brian (Patriot) wrote: Any other ideas? I keep updating but so far all I can do is launch an Xterm manually and clean up, then everything seems fine til the next time I relaunch it. --- Do you have DISPLAY=:0 set in your Windows environment? (system properties, Advanced, Env Vars). I put mine in the System Environment so it's there no matter how I'm logged in. -- 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/
extensions (shared mem, security)
looking at the startup log, I don't see the X-Security extension being initialized. Is it not supported? Also, perhaps more important for me is the message: 2009-12-15 10:39:27 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel NT supports shared memory objects and I thought cygwin uses shared memory for cross-process communication. So what's this about X not knowing about the shared memory support? 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: extensions (shared mem, security)
Yaakov (Cygwin/X) wrote: On 15/12/2009 13:00, Linda Walsh wrote: looking at the startup log, I don't see the X-Security extension being initialized. Is it not supported? http://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html ...and... You need to install and run the cygserver service before launching XWin in order to have support for XFree86-Bigfont and MIT-SHM. --- Damn useful response. What can I say, but thanks for the str8-up. :-) Guess I have more configurations changes to make... -l -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.10.3-1
Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.10.3-1 *** xorg-server-dmx-1.10.3-1 How can I install 'just' those packages (from the command line) The GUI has no option to only install 1 package -- it selects ALL, (100's of my packages want updates, but when I tried I tried it last, I ended up with a completely non-function cygwin setup (no bash, nada..., thank goddess I had a backup...) So now now, I tried going through and unselecting, but there were too many and my wrists gave out.and of course the GUI has not KB-accelerators like shift-minus to unselect all, that I could find. Any easy way to cherry pick packages to install rather than being forced fed entire updates all at once? the cmd line 'setup' claims to allow you to install, one package, but then it went through the whole gui process and still had all the other default packages installed! -- 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: X on win 7
Daniel Bienstock wrote: Hello, I have a new Dell Dimension M6600 with Windows 7 SP 1. I have disabled the Windows firewall and added rules to allow programs in cygwin and cygwin\bin to run. I am using cygwin 1.7.9 (I also use older cygwins on many 32-bit Windows machines). On this machine, X runs badly: often very slowly, and frequently with crashes as well. A couple of times I was forced to reboot the machine -- Windows appeared unresponsive. I did try rebaseall, but did not help (in fact had to reinstall cygwin). I have seen some posts on this topic, but no definitive workaround. --- This may be entire unhelpful, but is mentioned as a datapoint only, I have X on Win7 working with cygwin 1.4.2-1 and xorg-server 1.8.0-1 xorg-server-dmx 1.8.0-.1 (and lots of other packages from that era I tried upgrading to latest, and nothing worked. No bash, No X, -- rebase died didn't solve anything .. I reverted as didn't have the time to track down all the problems of such a large update. I'd like to try updating packages 1-by-1, but that's not easily supported through setup (it selects all, and there's no way to unselect the 100+ updates except by repetitious mouse clicks (keyboard accel's didn't function). My wrists warned me to quit. Dunno wazzup w/newer versions as I'm sure many use them with no difficulties, BUT, the version I have now works with what I currently have installed (BLODA, though I don't think I have anything that falls into that category, given it's precise definition, it's hard to tell from day-to-day). So things keep changing in both Win7, and cygwin, (and my server, that I upgraded to a changed samba(3.6) hasn't done me any favors in tracking down all my little nuisances Note, it's generally the cyg-support way to blame things on the user or tell them they can use the source and fix it themselves. Tried that 3 times, insufficiently documented and/or included too many assumptions about user's environment for me to replicate. (Doesn't mean I won't try again some day, but fixing my samba server handing out Domain GUID's is higher prio -- as is writing my script to create auto-snap-shots of my home-dir on linux with LSM and rsynch that are mounted w/samba so as to show up as previous versions of changed files (and of course, those tasks are always getting interrupted as well... nested so damn deep, I've my overflow counter has wrapped. -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.10.3-1
Christopher Faylor wrote: On Tue, Jul 19, 2011 at 07:25:50PM -0700, Linda Walsh wrote: Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.10.3-1 *** xorg-server-dmx-1.10.3-1 How can I install 'just' those packages (from the command line) The GUI has no option to only install 1 package -- it selects ALL, (100's of my packages want updates, but when I tried I tried it last, I ended up with a completely non-function cygwin setup (no bash, nada..., thank goddess I had a backup...) So now now, I tried going through and unselecting, but there were too many and my wrists gave out.and of course the GUI has not KB-accelerators like shift-minus to unselect all, that I could find. Any easy way to cherry pick packages to install rather than being forced fed entire updates all at once? the cmd line 'setup' claims to allow you to install, one package, but then it went through the whole gui process and still had all the other default packages installed! If you ran setup.exe and it deleted bash then there is something very seriously wrong with either your system or setup.exe. I know where my money would go if I was betting on which of the above was more likely. --- Didn't delete it... it was all non-functionalbash, everything dumped core or stacktraced -- symptoms of needing a rebase, but that didn't fix everything. .. Got bash to run but then still no X, and bash wouldn't run under 'Console' (only under native win cmd-like shell). You wanna put money on fault? Gee, Console worked w/old bash, installed, new bash, no longer works -- what changed? X used to work, update? Not. Fault? I wasn't pointing finger, BTW, I know my config isn't standard...BUT...that doesn't mean an update should through everything into chaos... -- 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: segfault Xserver...current version (1.8)
Jon TURNEY wrote: On 05/08/2011 01:02, Linda Walsh wrote: /var/log/XWin more XWin.0.log [ 58452.716] winInitMultiWindowWM - XOpenDisplay () returned and successfully op ened the display. [ 58452.716] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. [ 58452.732] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 58458.145] Segmentation fault at address 0x0 [ 58458.145] Fatal server error: [ 58458.145] Caught signal 11 (Segmentation fault). Server aborting [ 58458.145] ~ ~ I just upgraded to the new server last night... Next time, please *attach* the *full* XWin.0.log --- That was the full log...it had been truncated -- perhaps by the failing processes...A full log from a non-crashed version (i.e. I haven't run yast2), is here: /var/log/XWin more XWin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.10.3.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.10.3-1 built 2011-07-19 XWin was started with the following command line: /usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 2560 h 1600 winInitializeDefaultScreens - native DPI x 120 y 120 [ 938.034] (II) xorg.conf is not supported [ 938.034] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more in formation [ 938.034] LoadPreferences: Loading //Bliss/law/.XWinrc [ 938.049] LoadPreferences: Done parsing the configuration file... [ 938.190] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 938.190] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 938.190] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowD DNL [ 938.221] winDetectSupportedEngines - Returning, supported engines 001f [ 938.221] winSetEngine - Multi Window or Rootless = ShadowGDI [ 938.221] winScreenInit - Using Windows display depth of 32 bits per pixel [ 938.221] winAllocateFBShadowGDI - Creating DIB with width: 4480 height: 1600 depth: 32 [ 938.221] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 938.221] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [ 938.221] winInitMultiWindowWM - Calling pthread_mutex_lock () [ 938.221] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [ 938.221] Screen 0 added at virtual desktop coordinate (0,0). [ 938.283] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 938.283] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 938.642] winPointerWarpCursor - Discarding first warp: 2240 800 [ 938.642] (--) 7 mouse buttons found [ 938.642] (--) Setting autorepeat to delay=250, rate=31 [ 938.642] (--) Windows keyboard layout: 0409 (0409) US, type 4 [ 938.642] (--) Found matching XKB configuration English (USA) [ 938.642] (--) Model = pc105 Layout = us Variant = none Options = none [ 938.642] Rules = base Model = pc105 Layout = us Variant = none Optio ns = none [ 938.642] winBlockHandler - pthread_mutex_unlock() [ 938.642] winInitMultiWindowWM - pthread_mutex_lock () returned. [ 938.642] winInitMultiWindowWM - pthread_mutex_unlock () returned. [ 938.642] winMultiWindowXMsgProc - pthread_mutex_lock () returned. [ 938.642] winInitMultiWindowWM - DISPLAY=:0.0 [ 938.642] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [ 938.642] winProcEstablishConnection - winInitClipboard returned. [ 938.642] winMultiWindowXMsgProc - DISPLAY=:0.0 [ 938.642] winClipboardProc - DISPLAY=:0.0 [ 938.642] winInitMultiWindowWM - XOpenDisplay () returned and successfully op ened the display. [ 938.658] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. [ 938.673] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 4096.679] OS has icon alpha channel support: yes --- 1.8.0-1 is not the current version, 1.10.3-1 is (See [1]). I'm running 1.10.3.1 as you can see from the full log... I will now crash my xserver... [duplicate portions of above log suppressed...exactly the same timestamps up to [4096.679]]. [100813.992] Segmentation fault at address 0x0 [100813.992] Fatal server error: [100813.992] Caught signal 11 (Segmentation fault). Server aborting [100813.992] --- I've no idea why the original log was truncated 'funny', other than I'd tried to start and had crashed the server several times in a row, so it's possible in the multiple invocations one log overwrote another. Works fine for most things... But ran yast2, on my suse box kills it every time. w/signal 11. If this is still reproducible when you've upgraded to the current version of the Xserver, can you tell me what SuSE version you are using, please? Suse 11.4 Ishtar: rpm -qa|grep -P '(?:patterns
Re: segfault Xserver...current version (1.8)
Csaba Raduly wrote: On Sat, Aug 6, 2011 at 8:01 PM, Linda Walsh wrote: Jon TURNEY wrote: (snip) Next time, please *attach* the *full* XWin.0.log --- That was the full log...it had been truncated -- perhaps by the failing processes...A full log from a non-crashed version (i.e. I haven't run yast2), is here: To attach is to use File-Attach-File... or click the paperclip icon, as opposed to pasting the log into the body of the message. Ah...I focused on the 'full' part, not the attached part. It's just damn confusing. One list, filters attachments, another, they expect it... ARG! Also, please set Thunderbird to attach files correctly: --- Don't worry, Have done so in the past, forgot that this list *wants* them as attachments (vs. some others lists where such will be automatically stripped)... http://blog.crox.net/archives/23-How-to-set-thunderbird-to-correctly-attach-text-files-with-Content-Disposition-attachment-instead-of-inline.html Yeah -- that's why I don't like to include cygcheck.out's They give out lots of info that isn't _entirely_ relevant. It's not even an accurate package listing if one has installed packages w/tar by hand. What you deem relevant may not match what others on this list deem relevant. You might omit information that would have helped diagnosing your problem. There's a reason for what's written in Problem reports: http://cygwin.com/problems.html --- There are reasons for everything we come up with. That doesn't mean they are _always_ good reasons. Note I did try to underline the word entirely, AND, I did include it, whatever my reservations. I was merely commenting on how, in some cases it provides 'random goose chase' information. More often than not, I've seen it used to blow off user bug reports because some i isn't dotted, or t, crossed. Whatever, I understand, which isn't to say I always necessarily enjoy it -- but in this circumstance, considering the abstractions and mixtures of SW, I thought such a report more than reasonable to provide. I'm just wondering if there's a way to turn on coredumps and give stack traces of the X I'm running vs. downloading some 'extra special' version. I get coredumps on linux and windows, and am able to generate backtrace info on both for many situations (more on linux than windows), sometimes it leads me to investigate things more on my own and even find workaround or fixes, but the X server hasn't crashed on me since the last report, (but I am steering away from running yast2 for the time being!) C'est la vie Cheers! 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: segfault Xserver...current version (1.10, not 1.8)
Jon TURNEY wrote:. Does this mean that the xorg-server version reported by cygcheck is incorrect because you've installed the tar file by hand? --- apparently. I just cannot understand how you could paste your cygcheck.out, but not mention that important fact. I cannot understand how you cannot understand that I'd have no inherent clue how cygcheck would work or fail -- and that by taking a cygwin-setup tar image from it's setup dir, and installing it by hand, and then 'hand-calling' it's post-install script, wouldn't update the versions for cygcheck. I was surprised when you highlighted the wrong version. I did run the post-install scripts for the package. Perhaps it they need to call some common update routine that didn't get called to update the version? Sounds like a case of the tar and post-install scripts expecting things to be done, that are not clearly spelled out anywhere. So, how would would you have expected me to know that? Magic? It's not like I've had to do it before. Just that setup is broken -- and won't install single packages without alot of effort (as at least one other person posted!), So please be aware, I didn't know that cygcheck relied on some private-static database may have little to do with the actual system (files could have been restore, as well -- in fact WERE!...in the /bin dir, when nothing worked, I guess I thought cygcheck looked at version numbers in the binaries...but ... well silly me (hey, if it was something I relied on, I'd want it to tell me what the actual binaries are, not just what some static db thinks they are...but...that's me, and I'm used to things not always being the way the 'should' be...(so you have to program for the unexpected!)... Also, don't do that, it's not supported. --- Installing single packages is supposed to be supported, it's broken. What is the workaround? Regarding a stack traceback -- I dont' see where the Xserver has produced a corefile to run gdb on (???). Does it produce one? No. --- Oh. I try to config most of my apps to generate core dumps so I can get tracebacks of the actual problem that occurred in the actual binary that it occurred in. The instructions below don't say anything about getting a stack backtrace for the binary I'm running. They talk about downloading a different binary that may not reproduce the problem. In which case, I don't know if the problem is solved, or something just didn't step on something, randomly in memory due to some flailing pointer. Anytime you substitute a binary, getting a stacktrace or trying to produce a problem becomes an iffy proposition, because you aren't using the same program. That said, I suppose I don't care that much, other than to get the problem fixed at some point...so when I get time, I'll move forward with trying the instructions below... Which, BTW, I had already read before I asked about the coredumps for the current binary -- (I'd like to know how to enable coredumps for the current binary! not a different one, but that may not be possible -- you might think about being able enable it in the future based on some ENV setting...just a thought)... As I said once already: --- Yes you did, but that wasn't my question -- all I asked was about core dumps for the current binary. I didn't say I wouldn't do the below -- nor did I say the below told me to use the core dumps from my current binary... It was a related question, but not about how to do the 'below'...sorry if that was confusing... Following the instructions at [2] to obtain an Xserver backtrace would also be of great help. [2] http://x.cygwin.com/devel/backtrace.html -- 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: segfault Xserver...current version (1.10, not 1.8)
Jon TURNEY wrote: Following the instructions at [2] to obtain an Xserver backtrace would also be of great help. [2] http://x.cygwin.com/devel/backtrace.html Reading symbols from /usr/bin/Xwin...(no debugging symbols found)...done. Attaching to program `/usr/bin/Xwin', process 5280 [New Thread 5280.0x15b4] [New Thread 5280.0xcf4] [New Thread 5280.0x74c] [New Thread 5280.0x4a4] [New Thread 5280.0xe9c] [New Thread 5280.0xf64] [New Thread 5280.0xccc] [New Thread 5280.0x11a4] [New Thread 5280.0x1594] [New Thread 5280.0x818] [New Thread 5280.0x15bc] [New Thread 5280.0x15e0] [New Thread 5280.0x1514] (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5280.0x15b4] 0x00554823 in ?? () (gdb) bt #0 0x00554823 in ?? () #1 0x00544023 in ?? () #2 0x0058401e in ?? () #3 0x0052ad57 in ?? () #4 0x0052028a in ?? () #5 0x61007038 in _cygwin_exit_return () from /usr/bin/cygwin1.dll #6 0x0007 in ?? () #7 0x00fb1e08 in ?? () #8 0x61004c96 in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*) () from /usr/bin/cygwin1.dll #9 0x in ?? () (gdb) -- 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: X still crashing, but interesting log messages... different config vals needed?
Jon TURNEY wrote:
On 11/02/2012 04:19, Linda Walsh wrote:
Still crashes in all the places it did 2 months ago, and more, but
gives more interesting messages in log file (/var/log/xwin/XWin.0.log
I assume this refers to the problem reported in [1], crashing when running
yast2 on SuSE 11.4. I don't know anything about any other crashes you might
have been experiencing.
I haven't done anything specific to try to fix this, because I can't reproduce
the problem and I don't have a useful backtrace.
It would be of great help if you could follow the instructions at [2] to
download the debug symbols and obtain a backtrace of the crash.
I did that last time, then got another email from another admin saying
to try some other version instead of that one because the instructions were
wrong.
At that point, I gave up to go use Xming which didn't have the problem,
and was hoping someone else would run into it, since with cygwin, I have had it
set on autostart, and it usually crashes within 15-20 minuts -- make kernel, or
almost any qt based util,... then I just start Xming -- which was stable until
this last cygwin update...which doesn't make sense, as I didn't think there was
any code overlap
(main thing is I can no longer click on 'X' in a window and have it close, I
have to go through the program's menus in each program to close it...very
annoying.
Was wondering if I should be giving any different options that might
help it behave better?
Log from last run below --
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.11.4.0
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.11.4-3 built 2012-02-05
XWin was started with the following command line:
/usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm
[ 14334.463] SocketUNIXAccept: accept() failed
This log looks normal apart from this line.
I don't think this is a new warning, and wasn't in the previous log you
posted, so it's hard to see how this could be directly related to the problem.
On the other hand, I'm a bit surprised that it works at all after that error.
Nevertheless, since UNIX sockets don't seem to be working correctly for you,
you might like to try adding '-nolisten unix' to see if that makes any
difference.
On 11/02/2012 03:53, Linda Walsh wrote:
Re: oh forget the cygcheck...
(attached)..
cygwin = '() { return 0
}'
While I doubt that is is relevant, that's either a bug in cygcheck or a rather
strange setting for the CYGWIN env var
---
'cygwin' shown' there is lower case...
it does make a difference in the environment (case that is()... it's
a function in my startup where I detect if I am on cygwin, then define
a func that returns shell true (0), else on linux would return 1...
then other parts in my startup script can use that
cygwin . cygwin/xxx
or
cygwin || unixthing...
[1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00012.html
[2] http://x.cygwin.com/devel/backtrace.html
--
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: X still crashing, but interesting log messages... different config vals needed?
On Feb 12, 2012, Linda Walsh wrote: Jon TURNEY wrote: [ 14334.463] SocketUNIXAccept: accept() failed This log looks normal apart from this line. I don't think this is a new warning, and wasn't in the previous log you posted, so it's hard to see how this could be directly related to the problem. You mean you think it IS a new warning. Since I upgraded the Xserver the week before that last, I haven't been able to get *any* local 'X' programs to connect. Oddly enough, remote programs do connect. But I also can easily create a multi-gig /var/log file in a few hours, as that message repeats multiple times/second. FWIW, dbus always hangs now, (presumably it tries to connect to the X server), when I start a local terminal session, but one started on a remote system, seems to work, as I have it spawn in my .bashrc. Had to write some timeout code... so haven't forgotten about it... just been swamped by other probs...(so what else is new...)... -l -- 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: X still crashing, but interesting log messages... different config vals needed?
Jon TURNEY wrote: On 12/02/2012 23:51, Linda Walsh wrote: Jon TURNEY wrote: On 11/02/2012 04:19, Linda Walsh wrote: Still crashes in all the places it did 2 months ago, and more, but gives more interesting messages in log file (/var/log/xwin/XWin.0.log I assume this refers to the problem reported in [1], crashing when running yast2 on SuSE 11.4. I don't know anything about any other crashes you might have been experiencing. I haven't done anything specific to try to fix this, because I can't reproduce the problem and I don't have a useful backtrace. It would be of great help if you could follow the instructions at [2] to download the debug symbols and obtain a backtrace of the crash. I did that last time, then got another email from another admin saying to try some other version instead of that one because the instructions were wrong. I'm assuming you're referring to the exchange we had at [3], but I don't accept that as an accurate summary of it. Nevertheless, partly to prevent a re-iteration of that pointless debate, I have improved my build scripts so I now preserve the debug symbols for the packaged builds of XWin. Instructions on downloading them are available at [2]. At that point, I gave up to go use Xming which didn't have the problem, and was hoping someone else would run into it, since with cygwin, I have had it set on autostart, and it usually crashes within 15-20 minuts -- make kernel, or almost any qt based util,... then I just start Xming -- which was stable until this last cygwin update...which doesn't make sense, as I didn't think there was any code overlap Indeed, the only things they should have in common are your OS installation and your computer, which suggests to me, at least, that the problem may lie there. (main thing is I can no longer click on 'X' in a window and have it close, I have to go through the program's menus in each program to close it...very annoying. Was wondering if I should be giving any different options that might help it behave better? Log from last run below -- Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.11.4.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.11.4-3 built 2012-02-05 XWin was started with the following command line: /usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm [ 14334.463] SocketUNIXAccept: accept() failed This log looks normal apart from this line. I don't think this is a new warning, and wasn't in the previous log you posted, so it's hard to see how this could be directly related to the problem. On the other hand, I'm a bit surprised that it works at all after that error. Nevertheless, since UNIX sockets don't seem to be working correctly for you, you might like to try adding '-nolisten unix' to see if that makes any difference. I assume you didn't try this. [1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00012.html [2] http://x.cygwin.com/devel/backtrace.html [3] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00029.html -- 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: Glyph substitution
m...@safe-mail.net wrote: Glyph substitution doesn't works on cygwin using fontconfig, xft. Missing glyphs won't get replaced from ones existing in other fonts. Couldn't figure out why. Freshly installed cygwin. Anyone can report, that it should work? What would make you think it should work? I.e. where are you reading that it should work? Sounds neat...if it did... -- 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/
problem with opengl (glxgears) running on cygwin ....
When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Same effect happens when I try remotely. Window comes up with gears displayed, but no motion. Fraps also shows 30 FPS. When I do glxinfo (with LIBGL_DEBUG=verbose), I get (more below): name of display: :0 display: :0 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read, GLX_SGI_swap_control OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 590/PCIe/SSE2 OpenGL version string: 1.4 (4.4.0) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_framebuffer_object, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fog_distance, GL_NV_fragment_program, GL_NV_fragment_program2, GL_NV_fragment_program_option, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_packed_depth_stencil, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NV_vertex_program2, GL_NV_vertex_program2_option, GL_NV_vertex_program3, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_multi_draw_arrays, GL_SUN_slice_accum 98 GLX Visuals visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a F gb bf
Re: problem with opengl (glxgears) running on cygwin ....
Jon TURNEY wrote: Since [1], glxgears turns at a constant 70 degrees per second. --- 70 degress/s? How is that important? glxSwapBuffers does not block when used with indirect rendering, which means that lots of frames can be rendered almost instantly, with no apparent rotation, since the elapsed time between frames is very small. According to the text in the starting window it is rendering at 30FPS. -- I.e. it is sync'ed with my monitor's refresh rate (except for the 1st iteration when it acted unsynced) ... I.e. in starting window this was displayed: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 45623 frames in 6.4 seconds = 7166.903 FPS 834 frames in 27.4 seconds = 30.428 FPS 822 frames in 28.8 seconds = 28.542 FPS With all X-window response degraded (Xserver process was peg'ed@100%cpu), virtually no network traffic -- dropped from a norm of 200-400KB/s down to between 1KB-80KB/s. glxgears is a very basic test that GLX is functioning, and definitely not a benchmark. Real GLX clients should have a better mechanism for ensuring their animation rate doesn't outrun the vsync frequency. I thought it was the most basic. It claims (except for the 1st iteration) that it is not outruning my monitor's refresh rate. If you have any problems with real GLX clients, I would be interested to hear them. I'd be interested in finding any that work and proves that it works locally. While my initial use was to try remote GLX, I reverted to trying it localling -- just to verify it worked as it used to. Thats what brought this on. What is the OS of the remote system? --- linux (opensuse 13.1). No one else on that list was able to see normal response... some got really sluggish response, others saw no movement or nothing. It was only after I ran glxgears locally that I figured I might also have a problem in Cygwin's X, in addition to any other problem I have w/remote display. I think this is because glxgears will send frames as fast as it can, and can saturate the X server. The demo claims to sync at the same rate the monitor is refreshing. i.e -- 30 FPS. -- 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/
remote desktop /session bus woes...(was Re: problem with opengl (glxgears) running on cygwin ....)
Yaakov (Cygwin/X) wrote: On 2014-03-25 09:05, Jon TURNEY wrote: On 20/03/2014 08:41, Linda Walsh wrote: When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Thanks for pointing out this issue. I think that currently glxgears doesn't work very well with the combination of indirect rendering and vsync-limited buffer swapping, so you are getting 30 fps, but they aren't useful frames. This should be fixed in mesa-demos-8.1.0-2. FWIW, I tried another X server...VcXsrv?... Same with that program. I tried several, got some that worked, most didn't. Of the few that worked 'well' remotely, they were variations on the glgears... got about 400-500 FPS -- and about low 300's MB/s in bandwidth consumed... that sounds about right... but I think there are other problem in trying to get a remote desktop to work now... everything wants to connect to the session bus -- and many progs won't start if they can't. So if I can't figure out a way to get that to work, remote usage is left at a fairly primitive level despite the high frame rates on a 3x4 window... ;-) One of the demo progs said it required opengl 2.1 .. my card has V4.something. well above 2.1, so that seems like another latent problem. Will look for the fixed version ... thanks for the news... -- 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: running openGL application remotely using ssh -X and cygwin/x ,extension NV-GLX missing on display localhost:10.0
Jon TURNEY wrote: Yes, this should work. *But*, I'm pretty sure it doesn't anymore since the Xgl extension that was used to transport the openGL commands between client/server was removed from xorg's Xserver. From wikipedia: Xgl was a display server implementation supporting the X Window System protocol designed to take advantage of modern graphics cards via their OpenGL drivers, layered on top of OpenGL via glitz. It supported hardware acceleration of all X, OpenGL and XVideo applications and graphical effects by a compositing window manager such as Compiz or Beryl. The project was started by David Reveman of Novell and first released on January 2, 2006. It was removed[1] from the X.org server in favor of AIGLX on June 12, 2008. --- AIGLX doesn't work with client's native openGL drives when the DISPLAY isn't local. Instead, it sends full-frame-buffer updates to simulate what would be happening -- something that appears to work correctly for small OpenGL windows. But is entirely 'faked' (not really remote openGL that used the Server's acceleration Hardware. I'm not entirely clear if the 'extension �NV-GLX� missing' message is a warning or an error, but according to the internet it seems to be due to having a Nvidia libGL installed on the remote machine, so if all else fails you might look at uninstalling the Nvidia proprietary driver and libGL, and using mesa instead. Which would give you unaccelerated frame-buffer updates to simulate the effect. Not quite what used to be available. Note: this isn't a cygwin specific problem. i.e. people running xorg's server on a linux box have the same problem -- accelerated+remote 3D graphics seems to be dead. -- 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: remote xterm's can't open display after upgrade
JimE wrote:
Hi Don,
I'm in the same boat. I just upgraded cygwin and now I can't get remote xterms to
display on the local machine.
Question -- Is your local machine on a closed net?
I.e. My windows machine is on a local subnet (example: 192.168.x.y)
that isn't
(usually) exposed to the internet.
1st thing to note, is that my win X server starts automatically
when I log into windows (well it usually does unless some upgrade[sic]
makes something incompat), BUT, less likely to have problems, as
I start the X-server via my *own* script in my homedir's bin dir.
I.e. the shortcut on my QuickLaunch Bar (yeah, running W7 and still
using that...)... has
Target: C:\bin\bash.exe -c '%USERPROFILE%/bin/startxwin.sh'
Startin: %HOMEDRIVE%%HOMEPATH%
---
my startxwin.sh is mostly free of non-cygwin deps, except
for a tray-message util, notify which lets me put up messages
if the server is already running and such.
I'll leave in the comments (mostly NOTES to self or
OLD code...)... but if you know shell script, shouldn't be
hard to modify to your use case.
Some things (like a mount -c /) at the beginning
of the script have been added over the years to
increase robustness.
This script hasn't been cleaned for looking good
or best coding style, but given how often I need to
maintain or change it, I haven't been motivated.
It has disabled code that tried to start dbus, but
it didn't work reliably, so it's commented out.
Parts were rewritten to try to minimize use of non-shell,
external commands (minimize deps, efficiency).
Note 1: If you want to use this in an unsecure network,
then you need to start this through an ssh command to
the remote machine and not reset the DISPLAY...
Note 2: one thing this script does that the cygwin
script does not do -- it tries to read your display's
DPI and set the corresponding option in the X-display.
-extra config file: (optional)
~/.mind/Xserver-dflt-overrrides
+ac
-bash script: startxwin.sh
#!/bin/bash
# (c) LA Walsh 2004-2014, licenced under GPLv2 and/or to nice people
#export DISPLAY=:0
#export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
#export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
#export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
#export XNLSPATH=/usr/X11R6/lib/X11/locale
#unexport XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH
# see cygwin Xwin for more option examples
# relevant ops:
# -multiwindow = use windows manage; not w/(-rootless|-fullscreen)
# -clipboard = use built-in version (integrated w/windows)
# -unixkill = Enable Ctrl-Alt-BS as X-server shutdown cmnd
# -nowinkill = Disable Alt+F4 as a server shutdown key combination.
# -trayicon = (default) windows tray icon enabled
mount -c /
export PATH=/bin:$(/bin/cygpath $USERPROFILE)/bin:$PATH #ensure our
bin is 1st
shopt -s expand_aliases extglob
alias notify=$(type -P notifu)
alias int=declare\ -i
alias sub=function
alias xset=$(type -P xset);
alias array=declare\ -a
alias my=declare
export DISPLAY=${DISPLAY:-:0}
sub xup {
local stat
read -t .1 stat $(xset q /dev/null; echo $?)
return $stat
((-1))
}
sub Xwin_pids {
( cd /proc
for p in +([0-9])/ ;do
p2=${p%/}
prg=$(${p2}/exename)
if [[ $prg =~ .*XWin ]]; then
printf %d:%s\n $p2 $prg
fi
done
)
}
#sub Xwin_pid { echo $(/bin/ps -s|/bin/awk -- '/\?.*XWin/{print $1}') ; }
sub Xwin_pid {
array Xprgs
readarray Xprgs (Xwin_pids)
if ((!${#Xprgs[@]}));then
echo 0
return 1
fi
my x=${Xprgs[0]}
my pid=${x%%:**} prg=${x##*:}
array out=( $pid $prg)
printf %s ${out[@]}
printf \n
return 0
}
sub Xwin_running {
int pd; my pg
read pd pg (Xwin_pid)
return $(((!pd)))
}
export -f Xwin_pids Xwin_pid
#sub Xwin_pid { echo $(/bin/ps -s|/bin/awk -- '/\?.*XWin/{print $1}') ; }
#export -f Xwin_pid
#sub Xwin_running { [[ $(Xwin_pid) ]] ; }
#export TERM=15 KILL=9
sub tidy_old_Xwin {
local -a sigs=(TERM TERM KILL) # try 2 TERMs then KILL upto maxsigs
int pd; my pg
int maxsigs=3 lastsig=${#sigs[*]}
while ((1)); do
read pd pg (Xwin_pid)
((pd)) || break
#int i=--maxsigslastsig ? lastsig:maxsigs
kill -${sigs[--maxsigslastsig ? lastsig:maxsigs]} $pd
((maxsigs)) || break
sleep 1
done
rm -fr /tmp/.X11-unix
}
sub get_dpi {
dpi=$(regtool -d get '/HKLM/Software/Microsoft/Windows
NT/CurrentVersion/FontDPI/LogPixels')
# check for insane values
((dpi50||dpi400)) dpi=96
echo $dpi
}
sub get_fontpath {
local
fontpath=/usr/share/TTF,built-ins,/usr/share/fonts/misc,/usr/share/fonts/100dpi
echo -n $fontpath
}
sub start_XWin {
local
fontpath=/usr/share/fonts/TTF,built-ins,/usr/share/fonts/misc,/usr/share/fonts/100dpi
int dpi=$(get_dpi)
cmd=/bin/run /bin/XWin ${dpi:+-dpi $dpi}
-nomultimonitors -clipboard -ac -unixkill -nowinkill -wgl
-bs -fp $fontpath -multiwindow
echo cmd=$cmd
$cmd
}
declare -a default_switches=(-dpi -clipboard -unixkill -nowinkill
solution for package startup scripts changing: do your own (was Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3)
Laurens Blankers wrote:
On 2-1-2015 21:10, schilpfamily wrote:
this has worked for years, now when i run this command, a window very
briefly blinks into existence but then goes away. any idea why this
would stop working now?
Because the default options in the distribution provided
startup script changed to a more secure setting, consistent with
upstream changes and the general atmosphere of security paranoia that
is gradually eroding usability (as security issues get alot more
attention than usability -- so much so, that while a benefit of computers
was that they could adapt to the user for a friendly user experience,
the opposite is becoming the standard. I.e. users are expected to
adapt themselves to the changing machine programs.
I start my X server on login -- which means it has to work
when called at login -- and I wanted to make sure I could pass
custom arguments for the font path (among other things). As
a result I simply wrote my own startup script that has it's
own defaults. I expect it to work until some argument I expect
to be there is deleted.
I don't instantly get new features and benefits that might
be invoked from the distribution script, but usually it starts, and
every once in a while I review it and the cygwin start scripts to see
if there is something I should change. But at least I don't get
caught by this particular problem.
I *do* still get caught by the installer overwriting
Windows mount points with physical directories which causes
various programs to stop functioning until I move the updated
files to the 'mount-point' and change the physdir back to
a mount point.
Anyway, ---
The script is started by a shortcut in:
C:\Users\YOURUSERID\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\Startup
That has a shortcut to 'bash' with arguments:
(Target:) C:\bin\bash.exe -c '/bin/setsid %USERPROFILE%/bin/startxwin.sh'
(Start in:) %HOMEDRIVE%%HOMEPATH%
(Run:) Minimized
It is also an icon on my 'Quick Launch' bar (i.e. in directory):
C:\Users\YOURUSERID\AppData\Roaming\Microsoft\Internet Explorer\Quick
Launch
---startxwin.sh---
#!/bin/bash
# (c) LA Walsh 2004-2014, licenced under GPLv2
#export DISPLAY=:0
#export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
#export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
#export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
#export XNLSPATH=/usr/X11R6/lib/X11/locale
#unexport XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH
# see cygwin Xwin for more option examples
# relevant ops:
# -multiwindow = use windows manage; not w/(-rootless|-fullscreen)
# -clipboard = use built-in version (integrated w/windows)
# -unixkill = Enable Ctrl-Alt-BS as X-server shutdown cmnd
# -nowinkill = Disable Alt+F4 as a server shutdown key combination.
# -trayicon = (default) windows tray icon enabled
mount -c /
export PATH=/bin:$(/bin/cygpath $USERPROFILE)/bin:$PATH #ensure our
bin is 1st
shopt -s expand_aliases extglob
alias notify=$(type -P notifu)
alias int=declare\ -i
alias sub=function
alias xset=$(type -P xset);
alias array=declare\ -a
alias my=declare
export DISPLAY=${DISPLAY:-:0}
sub xup {
local stat
read -t .1 stat $(xset q /dev/null; echo $?)
return $stat
((-1))
}
sub Xwin_pids {
( cd /proc
for p in +([0-9])/ ;do
p2=${p%/}
prg=$(${p2}/exename)
if [[ $prg =~ .*XWin ]]; then
printf %d:%s\n $p2 $prg
fi
done
)
}
sub Xwin_pid {
array Xprgs
readarray Xprgs (Xwin_pids)
if ((!${#Xprgs[@]}));then
echo 0
return 1
fi
my x=${Xprgs[0]}
my pid=${x%%:**} prg=${x##*:}
array out=( $pid $prg)
printf %s ${out[@]}
printf \n
return 0
}
sub Xwin_running {
int pd; my pg
read pd pg (Xwin_pid)
return $(((!pd)))
}
export -f Xwin_pids Xwin_pid
sub tidy_old_Xwin {
local -a sigs=(TERM TERM KILL) # try 2 TERMs then KILL upto maxsigs
int pd; my pg
int maxsigs=3 lastsig=${#sigs[*]}
while ((1)); do
read pd pg (Xwin_pid)
((pd)) || break
#int i=--maxsigslastsig ? lastsig:maxsigs
kill -${sigs[--maxsigslastsig ? lastsig:maxsigs]} $pd
((maxsigs)) || break
sleep 1
done
rm -fr /tmp/.X11-unix
}
sub get_dpi {
dpi=$(regtool -d get '/HKLM/Software/Microsoft/Windows
NT/CurrentVersion/FontDPI/LogPixels')
# check for insane values
((dpi50||dpi400)) dpi=96
echo $dpi
}
sub get_fontpath {
local
fontpath=/usr/share/TTF:tcp/ishtar:7100,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi
echo -n $fontpath
}
sub start_XWin {
local
fontpath=/usr/share/fonts/TTF,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi
int dpi=$(get_dpi)
cmd=/bin/run /bin/XWin ${dpi:+-dpi $dpi}
-nomultimonitors -clipboard -ac -unixkill -nowinkill -wgl
-bs -fp $fontpath -multiwindow
echo cmd=$cmd
$cmd
}
declare -a default_switches=(-dpi -clipboard -unixkill -nowinkill -bs
-ac -fp -multiwindow -wgl)
readarray -t args (
a=$default_switches[@];
Re: Disable xterm auto-wrap: Mess up vi-like command line
Paul wrote: If I disable auto-wrap, the vi editing at the comand line misbehaves when the line being edited is long, especially when yanking a lot of text and pasting it. I suppose that this might be technically correct behaviour, since an extra long command line needs to wrap in order to see it properly. But I use the vi command line exclusively, and almost always, I don't want autowrap in the results from commands being sent to the screen. Is there a way to get both at the same time, without having to always toggle the xterm autowrap? --- What do you mean by mess up? It shouldn't. I just cut and pasted some text from an xterm into an editor, and the lines weren't split... they got copied as one line. However, if I was to cut from a Windows Console window (cmd.exe for example), it DOES, physically, split long lines. It's a property of the console. The main problem I've seen in bash is when you paste content that has tabs in it. Then bash tries to auto complete in the middle of your typing... often asking a question or pausing -- which means it *swallows* up the tab and 1-2 keys after the tab. It didn't use to do this back in the 3.x series, but was added as a new feature in the 4.x series. I ended up changing my completion character to BACKQUOTE to try to get around this. Maybe tabs are causing your problem? Example. At a prompt, I typed: cat CR completion char (I hit enter after that first quote and went to the next line and hit my completion char (BACKQUOTE `), Then I got: cat Display all 186 possibilities? (y or n) --- At this point, whatever character is next in my paste buffer will be swallowed up (in addition to the completion character). --- Since the long line cut/paste worked for me in 'xterm', that's why I thought maybe you were hitting bash'es input mangling-feature!... -- 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/
