i have been running cygwin/x for a long time. i was on 1.14.4 and decided to upgrade to 1.16.3. the problem is that i am unable to start an xterm from a dos prompt. i have been using the following command line for years now: D:\cygwin\bin\run.exe -p /bin bash ~/scripts/xtermLaptop the contents of xtermLaptop are: #!/usr/bin/env bash export DISPLAY=127.0.0.1:0.0 xterm -geometry 80x75 -sb -rightbar & exit 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? -- 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/
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? This is most likely due to a major rewrite of the xinit package which contains all start-up scripts. If you downgrade the xinit package from 1.3.4-1 to 1.3.2-1 does your setup work again? Here is how you downgrade: 1. Start the Cygwin installer 2. Select the appropriate mirror and directories 3. In the package selection screen search for 'xinit' 4. Select the one from the 'X11' category and click on the version until it cycles to 1.3.2-1 in stead of 1.3.4-1. 5. Click Next and install If this does solve your problem you may want to read my request to the maintainers: https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html Laurens -- 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/
rolling back to 1.3.2-1 fixed it. thank you very much for this, i was really pulling my hair out on this. i read your request to the maintainers and fully agree. while i only brought up this one bug, since it was basically making cygwin/x useless, there were other issues that made it annoying. thanks again. bill On Fri, Jan 2, 2015 at 3:21 PM, Laurens Blankers <laurens@blankersfamily.com> 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? > This is most likely due to a major rewrite of the xinit package which > contains all start-up scripts. > > If you downgrade the xinit package from 1.3.4-1 to 1.3.2-1 does your > setup work again? Here is how you downgrade: > > 1. Start the Cygwin installer > 2. Select the appropriate mirror and directories > 3. In the package selection screen search for 'xinit' > 4. Select the one from the 'X11' category and click on the version until > it cycles to 1.3.2-1 in stead of 1.3.4-1. > 5. Click Next and install > > If this does solve your problem you may want to read my request to the > maintainers: > > https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html > > Laurens > > -- > 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/
On 01/02/2015 03:35 PM, schilpfamily wrote: > rolling back to 1.3.2-1 fixed it. thank you very much for this, i was > really pulling my hair out on this. i read your request to the > maintainers and fully agree. while i only brought up this one bug, > since it was basically making cygwin/x useless, there were other > issues that made it annoying. Certainly it is good feedback to know that the issue you were seeing is related to the new version of xinit. I would encourage you and others that see issues with the latest release to report the problems (as you have) and to try the solutions offered in the cygwin-xfree mailing list discussions from the last couple of months. If there are technical issues with those solutions, they need to be reported as well. Obviously, the key thing here is to figure out how to make this transition smoother, so the more useful feedback there is, the better. Downgrading may be a practical short-term solution to the problems you're having at the moment and that's fine. But the functionality in the latest release of the xinit corrects some long-standing Cygwin incompatibilities with startx, so there's no benefit to turning back as a strategy. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/
On 3-1-2015 04:48, Larry Hall (Cygwin-X) wrote: > But the functionality in the latest release of the xinit corrects some > long-standing Cygwin incompatibilities with startx, so there's > no benefit to turning back as a strategy. This is exactly why I have such hard time convincing people that using open source software is a good idea: "The solution is technically better, so if it breaks for you I don't care." I am not arguing that the solution should be discarded, I am arguing that the way the transition was handled, or not handled actually, it not worthy of being called engineering, development, or even programming. The best, and actually only way to move forward is to revert back to the behaviour of 1.3.2-1 and rethink this whole approach. Once a good transition plan is in place the changes can be reapplied. But it is obvious that I won't find a sympathetic ear to the plight of the user here, so I will escalate this to the main Cygwin mailing list. Hopefully people their actually care about user experience. Laurens -- 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/
On January 3, 2015 12:03:58 AM PST, Laurens Blankers <laurens@blankersfamily.com> wrote: >I am not arguing that the solution should be discarded, I am arguing >that the way the transition was handled, or not handled actually, it >not >worthy of being called engineering, development, or even programming. Strong words, but absolutely correct. Transitions affecting the user experience should be gradual, not violent. This was an unnecessarily violent transition with much breakage. Revert, replan, redeploy. -BobC -- 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/
On 01/03/2015 03:03 AM, Laurens Blankers wrote: > On 3-1-2015 04:48, Larry Hall (Cygwin-X) wrote: >> But the functionality in the latest release of the xinit corrects some >> long-standing Cygwin incompatibilities with startx, so there's >> no benefit to turning back as a strategy. > This is exactly why I have such hard time convincing people that using > open source software is a good idea: "The solution is technically > better, so if it breaks for you I don't care." Interesting that you should gather that from my comments, since I never said I don't care nor do I believe that the maintainer doesn't care. Seems to me like you're attributing perceptions you've gathered from other people and interactions in your life to me. Please don't do that. My point, which I will reiterate again because I think it received overtones I wasn't conveying the first time, is that the changes made are indeed needed and beneficial in general. You can find evidence of this in the email archives. Removing the newly introduced changes means these other folks that expect Cygwin's X to work like it does on Linux and other platforms will continue to be surprised, etc. The fact that the recent changes interfere with previous usage is an issue that needs attention for sure but reverting, while the maintainer's call, just trades misbehaviour in the eyes of one group for that of the other. And the individual is always free to revert the package version in the short-term to address any immediate need. So with the short-term bases covered, it makes sense to move forward by looking and going forward. I encourage those that want to smooth the transition to help by trying the solutions so far and offering feedback on what works well and what doesn't. This is the way we can reach a solution that addresses the concerns of both groups. <snip> > The best, and actually only way to move forward is to revert back to the > behaviour of 1.3.2-1 and rethink this whole approach. Once a good > transition plan is in place the changes can be reapplied. But it is > obvious that I won't find a sympathetic ear to the plight of the user > here, so I will escalate this to the main Cygwin mailing list. Hopefully > people their actually care about user experience. I think your point has been heard. There's no need to take it to another Cygwin list or reiterate it here. Since the issue is related to the changes in the xinit package and this is the list for X issues, you have the right forum if you want to help work towards a smoother transition for existing users with the xinit package. The Cygwin main list is really for everything but X. Talking about X things there will likely get you redirected back to this list. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/
On 2015-01-04 00:02, Larry Hall (Cygwin-X) wrote: > The fact that the recent > changes interfere with previous usage is an issue that needs attention > for > sure but reverting, while the maintainer's call, just trades misbehaviour > in the eyes of one group for that of the other. That may be true, but you are prioritizing new users over your existing user base here. There are many many users out there for which the behaviour as exhibited by 1.3.2-1 has worked for many years. Behaviour which is now broken, without even the slightest hint of what is going on! And without a way to get all the functionality back, even with changes! > I encourage those that want > to smooth the transition to help by trying the solutions so far and > offering feedback on what works well and what doesn't. This is the > way we > can reach a solution that addresses the concerns of both groups. I would like to help smoothing the transition, however not by forcing changes down peoples throats and then saying may be when can make this better some time in the future. If you want my help, do the right thing, acknowledge that the way of handling this was wrong. Revert the changes. And solicit the help of the people on this mailing list to come up with a well designed, well tested, and well documented solution. > I think your point has been heard. There's no need to take it to another > Cygwin list or reiterate it here. I don't think so. You maintain that the approach chosen was the right one. I think the saying in English is "It Takes a Real Man to Admit when He's Wrong". I am sorry, I can't help you if you keep maintaining nothing went wrong. Laurens -- 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/
On 01/04/2015 06:41 AM, Laurens Blankers wrote: > On 2015-01-04 00:02, Larry Hall (Cygwin-X) wrote: >> The fact that the recent >> changes interfere with previous usage is an issue that needs attention for >> sure but reverting, while the maintainer's call, just trades misbehaviour >> in the eyes of one group for that of the other. > That may be true, but you are prioritizing new users over your existing user > base here. There are many many users out there for which the behaviour as > exhibited by 1.3.2-1 has worked for many years. Behaviour which is now > broken, without even the slightest hint of what is going on! And without a > way to get all the functionality back, even with changes! > >> I encourage those that want >> to smooth the transition to help by trying the solutions so far and >> offering feedback on what works well and what doesn't. This is the way we >> can reach a solution that addresses the concerns of both groups. > I would like to help smoothing the transition, however not by forcing > changes down peoples throats and then saying may be when can make this > better some time in the future. > > If you want my help, do the right thing, acknowledge that the way of > handling this was wrong. Revert the changes. And solicit the help of the > people on this mailing list to come up with a well designed, well tested, > and well documented solution. > >> I think your point has been heard. There's no need to take it to another >> Cygwin list or reiterate it here. > I don't think so. You maintain that the approach chosen was the right one. I > think the saying in English is "It Takes a Real Man to Admit when He's > Wrong". I am sorry, I can't help you if you keep maintaining nothing went > wrong. So I'm guessing with your statement above that English isn't your primary language. If true, then perhaps that's why you keep saying I've made statements I didn't make. You say above that I "keep maintaining nothing went wrong." And yet you quoted me in your response saying "The fact that the recent changes interfere with previous usage is an issue that needs attention...." If this is really just a language issue, then I understand but let's try to avoid it in the future. If not, I have to again ask you not to attribute statements you make as ones I have made. If you persist, I won't continue to respond to your thread, assuming there would be any redeeming value to continuing this thread at this point. OK, let me try to be as clear as possible: 1. I am not the maintainer of the xinit package. That is Yaakov Selkowitz. You can see this by his announcement of the latest version. <https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html> So when I say that how the upgrade of the xinit is handled is up to the maintainer, I mean it is up to Yaakov, not me. 2. Yaakov is a very capable and prolific contributor to the Cygwin project and has been for many years. Because of his many hats and tasks, others (including me), from time to time, try to help people with issues they see, even if the package or packages in question are maintained by someone else (and this is the case with xinit as I mentioned above). 3. There have been a number of related issues that have popped up relative to the latest version of xinit. I've listed quite a few entry points to the relevant threads. You'll notice that sometimes Yaakov is answering the question raised and other times others are doing it. That's standard operating procedure. <https://cygwin.com/ml/cygwin-xfree/2014-11/msg00038.html> <https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html> <https://cygwin.com/ml/cygwin-xfree/2014-11/msg00041.html> <https://cygwin.com/ml/cygwin-xfree/2014-11/msg00043.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00000.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00002.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00008.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00009.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00028.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00048.html> <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00057.html> When I mentioned above that you or others can help out by pointing out where the solutions proposed fall short, I wa referring to the solutions offered in the threads above, in case it wasn't clear to anyone. I gather from your comments in <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html> that the only issue that you're aware of that isn't addressed by the solutions offered so far is the one about the icon showing in the task bar rather than the tray. If you or others know of other issues, that would be useful to report. 4. I realize that you have a policy issue that you raised as a result of your xinit upgrade experience, which you posted about in <https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html> and have subsequently taken to the Cygwin main list <https://cygwin.com/ml/cygwin/2015-01/msg00030.html>. The policy question of managing package updates, I submit, is separate from getting current installations running after the xinit 1.3.4-1 upgrade, since this update is already here and for all the reasons I've stated previously. So I withdraw my previous request that you not post your policy question to the Cygwin main list (since I agree it is a general issue) but instead request that you only discuss the policy and not overlap with the specifics covered in the xinit package threads, since that will take it into X-land which takes it off-topic on the main list. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/
On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote: > So I'm guessing with your statement above that English isn't your primary > language. > [..] > 1. I am not the maintainer of the xinit package. [..] English is indeed not my first language, but that is no excuse for not carefully reading your replies and not verifying assumptions about you being a maintainer. I did not read your replies carefully enough and did not check my assumptions. Please accept my apologies. > [..] > 2. Yaakov is a very capable and prolific contributor to the Cygwin project > and has been for many years. [..] I do appreciate your (yours, Yaakov's, and others) efforts very much. I tried to express that in the last paragraph of my original mail [1]. Please tell me if this intent did not come across or was drowned somehow, so I can phrase it better next time. > [..] > You'll notice that sometimes Yaakov is answering > the question raised and other times others are doing it. That's > standard operating procedure. [..] I did read all the previous questions and answers. I interpreted the focus on having users change their configuration rather than changing the xinit package as a denial of the problem. However, now I see that none of the replies were by the package maintainer. I now realize that you were doing the best you could in helping me and others. > [..] > When I mentioned above that you or others can help out by pointing out > where the solutions proposed fall short [..] As far as I can tell, from the available information, users which meet any of the following criteria will run into trouble: - Custom .startxwinrc or .xinitrc - Using untrusted X11 forwards over SSH (e.g. ssh -X or PuTTY) My assumption is that this covers the vast majority of xinit users. Including these which previously complained about the non-standard way of handling configuration. As a software engineer I strongly believe in the principle of least astonishment [2]. At least for the vast majority of users. In this case, in my opinion at least, that would mean that changing the behaviour of startxwin should be done in such a way as to provide a seamless way of users to upgrade. Preferably by maintaining compatibility with existing configurations, or by automatic conversion, or, if necessary through a well documented manual transition process. What I am trying to say is that I don't object to your solutions, but I would really like this to be solved in a way that provides a create user experience. For me that would mean that the first step would be to retract the update (revert back to 1.3.2-1) as to prevent more users from running into problems. I do realize that that would mean forcing people who have already converted to go back. But I assume this is a minority of users. Then I would propose to evaluate what could be done to provide a smooth transition, possibly over a longer time, popping up increasingly annoying warnings about the configuration, for example. I would like to help with this. I think I can assist in figuring out what kind of configurations are out there, as well as in testing, and in writing documentation. I could even code the solution, but that would probably be more efficient of people with more experience in bash scripting would do that. > [..] > So I withdraw my previous request that you not post > your policy question to the Cygwin main list (since I agree it is a > general issue) but instead request that you only discuss the policy and > not overlap with the specifics covered in the xinit package threads [..] Thank you, I would like to discussion on the general list to be broader. Because, for me, this issue was highlighted by xinit, but is by no means related to it. I, and I assume many others, rely on Cygwin and also assume, possibly incorrectly, that it will continue to function as expected, after applying (security) updates. An incompatible change in any other package would also be problematic for me. The reason I mentioned xinit explicitly is to provide the reader with a background, and as soft of a 'full disclosure' of my involvement. I will also make it very explicit on the common list that the post is not specific to xinit, but that is merely serves as an example. > A: Yes. > > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. > >>> Q: Why is top posting annoying in email? I really like your signature, do you mind if I borrow/steal it? Laurens [1] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html [2] http://en.wikipedia.org/wiki/Principle_of_least_astonishment -- 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/
On 2015-01-05 03:06, Laurens Blankers wrote: > On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote: > As far as I can tell, from the available information, users which meet > any of the following criteria will run into trouble: > > - Custom .startxwinrc or .xinitrc Just .startxwinrc, and the changes were explained in the announcement. > - Using untrusted X11 forwards over SSH (e.g. ssh -X or PuTTY) ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the FAQ for details). > As a software engineer I strongly believe in the principle of least > astonishment [2]. At least for the vast majority of users. In this case, > in my opinion at least, that would mean that changing the behaviour of > startxwin should be done in such a way as to provide a seamless way of > users to upgrade. Preferably by maintaining compatibility with existing > configurations, or by automatic conversion, or, if necessary through a > well documented manual transition process. That's what the announcement was for. > What I am trying to say is that I don't object to your solutions, but I > would really like this to be solved in a way that provides a create user > experience. For me that would mean that the first step would be to > retract the update (revert back to 1.3.2-1) as to prevent more users > from running into problems. I do realize that that would mean forcing > people who have already converted to go back. But I assume this is a > minority of users. Then I would propose to evaluate what could be done > to provide a smooth transition, possibly over a longer time, popping up > increasingly annoying warnings about the configuration, for example. I am not going to revert the recent changes, which are important and long overdue. If any has constructive suggestions for incremental improvements thereto, they will be duly considered, but going backwards is not the solution. >> So I withdraw my previous request that you not post >> your policy question to the Cygwin main list (since I agree it is a >> general issue) but instead request that you only discuss the policy and >> not overlap with the specifics covered in the xinit package threads [..] > > Thank you, I would like to discussion on the general list to be broader. That won't be necessary. As a rolling distribution without stable releases, these kind of changes in UX happen from time to time. That's what announcements are for. Yaakov -- 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/
On 5-1-2015 10:48, Yaakov Selkowitz wrote: > Just .startxwinrc, and the changes were explained in the announcement. The information is contained within the announcement, but it is a bit difficult to figure out what to do from just the list of changes. A more detailed step-by-step guide, preferably as part of the FAQ would be very much appreciated. > ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the > FAQ for details). I see, but PuTTY which apparently uses insecure forwards has worked for many years all the way up to 1.3.2-1. > That's what the announcement was for. As mentioned above a bit more guidance would be nice. > I am not going to revert the recent changes, which are important and > long overdue. If any has constructive suggestions for incremental > improvements thereto, they will be duly considered, but going > backwards is not the solution. OK, I am a bit disappointed, but I do have some suggestions. How would you prefer I post them? In this thread or a new one? All together or one post per suggestion? > That won't be necessary. As a rolling distribution without stable > releases, these kind of changes in UX happen from time to time. > That's what announcements are for. Are you saying it is inappropriate to discuss or that you personally don't see value in this? Laurens -- 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/
On 2015-01-05 04:03, Laurens Blankers wrote: > On 5-1-2015 10:48, Yaakov Selkowitz wrote: >> Just .startxwinrc, and the changes were explained in the announcement. > The information is contained within the announcement, but it is a bit > difficult to figure out what to do from just the list of changes. A more > detailed step-by-step guide, preferably as part of the FAQ would be very > much appreciated. I can't be everyone's personal IT department. I believe the information in the announcement contains sufficient information for users to make the necessary changes, but the most important part would be the new requirements of ~/.startxwinrc. >> ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the >> FAQ for details). > I see, but PuTTY which apparently uses insecure forwards has worked for > many years all the way up to 1.3.2-1. Then please provide complete details in a separate thread. >> I am not going to revert the recent changes, which are important and >> long overdue. If any has constructive suggestions for incremental >> improvements thereto, they will be duly considered, but going >> backwards is not the solution. > OK, I am a bit disappointed, but I do have some suggestions. How would > you prefer I post them? In this thread or a new one? All together or one > post per suggestion? Please start a new thread. >> That won't be necessary. As a rolling distribution without stable >> releases, these kind of changes in UX happen from time to time. >> That's what announcements are for. > Are you saying it is inappropriate to discuss or that you personally > don't see value in this? There is simply no point. Yaakov -- 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/
On 01/05/2015 04:06 AM, Laurens Blankers wrote: <snip> Since I believe the rest of what you wrote above has been covered in one form or another since my last reply, I won't bore anyone with my responses. This leaves just one very critical piece of business which absolutely must be addressed: >> >A: Yes. >>> > >Q: Are you sure? >>>> > >>A: Because it reverses the logical flow of conversation. >>>>> > >>>Q: Why is top posting annoying in email? > I really like your signature, do you mind if I borrow/steal it? Of course! I actually "borrowed" it from someone else a few lifetimes ago so it would hardly be sporting of me to deny you equal rights. :-) -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/
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=--maxsigs>lastsig ? lastsig:maxsigs kill -${sigs[--maxsigs>lastsig ? 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 ((dpi<50||dpi>>400)) && 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[@]"; IFS=$'\n'; echo "${a[*]#?}"|sort -k1.2 ) sub read_users_mind { #(reads file in lieu of HW support for actual) if [[ -O ~/.mind && -O ~/.mind/Xserver-dflt-overrides ]]; then readarray -t overrides < <( -x <~/.mind/Xserver-dflt-overrides perl -wnE ' chomp; s/\s*(?:#.*)?$//; s/^\s*// s/\s\s+/\s/ ; $_ || next; print $_."\n" ') fi typeset -a switches } sub start_dbus { /bin/run /bin/dbus-launch --exit_with_session ~/.Xsession } sub _in { local x=${1:?};shift for ((;$#>0;)); do [[ $x == $1 ]] && return 0;shift; done return 1 } int tries=3 if Xwin_running && xup; then notify /t info /m "Xserver already running and ready" /d 5000 else echo Cannot contact X Server tidy_old_Xwin while ((1)); do start_XWin $(read_users_mind) sleep 1 for ((i=0;i<5;++i)); do xup && break 2 sleep 1 done if ((--tries<=0)); then m="\aEXITING: Timeout Waiting for Xserver Startup!!" echo "$m" notify /t error /m "$m" exit 1; fi done #start_dbus || { m="\aError Starting Dbus"; echo "$m"; notify /t error /m "$m"; } fi # vim: ts=2:sw=2 -------------- > This is most likely due to a major rewrite of the xinit package which > contains all start-up scripts. ---- Not if you write your own -- then you will get your own "customized" behavior (so at least when it breaks, you have a chance to fix it yourself)... If you don't like mine, fine, copy the cygwin script and make the changes to it and call it the same way. At least you'll get whatever behavior you want and upgrades won't be altering your script... BTW, Laurens Blankers, the opensource model for developers doing their own thing is called a "do-acracy". Those that do, make the rules. Not saying it is a great thing, just putting a handle on it... ;-) -- 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/