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)

[Linda Walsh]

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\\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\\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

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Larry Hall (Cygwin-X)]

On 01/05/2015 04:06 AM, Laurens Blankers wrote:


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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Yaakov Selkowitz]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Laurens Blankers]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Yaakov Selkowitz]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Laurens Blankers]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Larry Hall (Cygwin-X)]

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.
   
   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.

   
   
   
   
   
   
   
   
   
   
   

   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
    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
    and have
   subsequently taken to the Cygwin main list
   

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Laurens Blankers]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Larry Hall (Cygwin-X)]

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.




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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[rcunningham]

On January 3, 2015 12:03:58 AM PST, Laurens Blankers 
 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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Laurens Blankers]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Larry Hall (Cygwin-X)]

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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[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.

thanks again.

bill

On Fri, Jan 2, 2015 at 3:21 PM, 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?
> 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/

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

[Laurens Blankers]

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/

run.exe will not work with upgrade from 1.14.4 to 1.16.3

[schilpfamily]

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/