Discussion:
run.exe will not work with upgrade from 1.14.4 to 1.16.3
schilpfamily
2015-01-02 20:10:56 UTC
Permalink
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/
Laurens Blankers
2015-01-02 20:21:12 UTC
Permalink
Post by schilpfamily
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/
schilpfamily
2015-01-02 20:35:26 UTC
Permalink
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
Post by Laurens Blankers
Post by schilpfamily
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
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
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/
Larry Hall (Cygwin-X)
2015-01-03 03:48:55 UTC
Permalink
Post by schilpfamily
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.
Post by schilpfamily
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
2015-01-03 08:03:58 UTC
Permalink
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/
r***@ucsd.edu
2015-01-03 09:24:46 UTC
Permalink
Post by Laurens Blankers
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/
Larry Hall (Cygwin-X)
2015-01-03 23:02:09 UTC
Permalink
Post by Laurens Blankers
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>
Post by Laurens Blankers
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.
Post by Laurens Blankers
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
2015-01-04 11:41:45 UTC
Permalink
Post by Larry Hall (Cygwin-X)
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!
Post by Larry Hall (Cygwin-X)
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.
Post by Larry Hall (Cygwin-X)
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/
Larry Hall (Cygwin-X)
2015-01-05 04:04:29 UTC
Permalink
Post by Larry Hall (Cygwin-X)
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!
Post by Larry Hall (Cygwin-X)
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.
Post by Larry Hall (Cygwin-X)
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?
Post by Larry Hall (Cygwin-X)
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
2015-01-05 09:06:49 UTC
Permalink
Post by Larry Hall (Cygwin-X)
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.
Post by Larry Hall (Cygwin-X)
[..]
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.
Post by Larry Hall (Cygwin-X)
[..]
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.
Post by Larry Hall (Cygwin-X)
[..]
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.
Post by Larry Hall (Cygwin-X)
[..]
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.
Post by Larry Hall (Cygwin-X)
A: Yes.
Post by schilpfamily
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/
Yaakov Selkowitz
2015-01-05 09:48:53 UTC
Permalink
Post by Laurens Blankers
As far as I can tell, from the available information, users which meet
- Custom .startxwinrc or .xinitrc
Just .startxwinrc, and the changes were explained in the announcement.
Post by Laurens Blankers
- 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).
Post by Laurens Blankers
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.
Post by Laurens Blankers
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.
Post by Laurens Blankers
Post by Larry Hall (Cygwin-X)
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/
Laurens Blankers
2015-01-05 10:03:39 UTC
Permalink
Post by Yaakov Selkowitz
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.
Post by Yaakov Selkowitz
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.
Post by Yaakov Selkowitz
That's what the announcement was for.
As mentioned above a bit more guidance would be nice.
Post by Yaakov Selkowitz
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?
Post by Yaakov Selkowitz
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/
Yaakov Selkowitz
2015-01-05 10:34:10 UTC
Permalink
Post by Laurens Blankers
Post by Yaakov Selkowitz
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.
Post by Laurens Blankers
Post by Yaakov Selkowitz
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.
Post by Laurens Blankers
Post by Yaakov Selkowitz
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.
Post by Laurens Blankers
Post by Yaakov Selkowitz
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/
Larry Hall (Cygwin-X)
2015-01-06 04:19:23 UTC
Permalink
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
Post by Laurens Blankers
Post by Larry Hall (Cygwin-X)
A: Yes.
Post by schilpfamily
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.
Post by Laurens Blankers
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Post by Larry Hall (Cygwin-X)
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/
Linda Walsh
2015-01-12 00:26:31 UTC
Permalink
Post by Laurens Blankers
Post by schilpfamily
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="EXITING: Timeout Waiting for Xserver Startup!!"
echo "$m"
notify /t error /m "$m"
exit 1;
fi
done
#start_dbus || { m="Error Starting Dbus"; echo "$m"; notify /t error
/m "$m"; }
fi

# vim: ts=2:sw=2
--------------
Post by Laurens Blankers
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/

Continue reading on narkive:
Loading...