Re: startxwin.exe no longer exists?
On 12/15/2014 6:49 PM, Will Parsons wrote: Marco Atzeri wrote: On 12/12/2014 7:07 PM, Will Parsons wrote: For several years now I have been starting X windows by clicking on an icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It has recently ceased to work because apparently startxwin.exe no longer exists. Somehow I missed where this was removed, so what is the recommended way of starting X from a desktop icon now? I seem to recall that startxwin.exe was introduced some time ago because using a script to start X was inadequate somehow, but I don't remember the details, so what changed? https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg4.html OK - so what I get from that is that whatever problems were associated with the original shell script have been solved and startxwin is now a shell script again. But, my basic question is unanswered - how do I start an X session from an icon? Obviously, simply replacing the link to startxwin.exe to startxwin will not work, so I copied the shortcut from the start menu to the desktop and tried it (after renaming my .xinitrc and .startxwinrc files to avoid any problems with the change of model). Here is the content of the desktop shortcut that I use: C:\Apps\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -emulate3buttons 100 -multiwindow -clipboard -swcursor I have this set to run when I log into the machine and it works fine. -- 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: startxwin.exe no longer exists?
On 12/16/2014 8:00 AM, Erik Soderquist wrote: snip Sure, display :0 is unavailable; checking DISPLAY in the (unwanted) xterm shows DISPLAY is set to :5. Why's that I wonder? Further investigation shows ls -ltr /tmp: -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock Interesting. It looks like every time I start an X session a lock file is created and doesn't get deleted, so the display number keeps changing. This doesn't look right, so how do I avoid it? -- Will What I do is specify the display on the command line. If it fails, I check for an existing operational session with the same display. If it exists, I simply exit the script. If not, I free the lock file and retry the X server start on the chosen display. -- Erik Shouldn't the startxwin script check for running instances and delete all lock-files related to non-existent instances? Why must this be a manual operation? The prior startxwin.exe just worked, and this new replacement script is clearly creating problems for previously happy CygwinX users, where no problems existed before (or, at least the problems weren't visible and didn't affect normal use). I would have preferred to have seen startxwin.exe retained, and this new script phased in gradually, perhaps as startxwin_new in the first release. Then, when startxwin_new stabilizes, rename the executable to startxwin_old.exe and the script to startxwin. Several updates later, quietly remove startxwin_old.exe. It seems nonsensical to treat all CygwinX users as alpha testers. I'm more than willing to help test new features, but not in the dark: Make it very clear when significant subsystems are being evolved, and provide a way to try the new without losing the old. For now, can startxwin.exe be restored under some name? -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: startxwin.exe no longer exists?
snip Shouldn't the startxwin script check for running instances and delete all lock-files related to non-existent instances? Why must this be a manual operation? I generally recommend against automagic cleanup of lock files from dead sessions being a general default because that also wipes out warning that something went wrong. I do it in my situation because I have it on (essentially) dumb terminals where the session working is much more important than knowing something went wrong, and the dumb terminals are on flaky power, so most of the dead sessions are due to power failure anyway. The prior startxwin.exe just worked, and this new replacement script is clearly creating problems for previously happy CygwinX users, where no problems existed before (or, at least the problems weren't visible and didn't affect normal use). I actually have no experience with startxwin; I always called the X server directly with the options I wanted. However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. I would have preferred to have seen startxwin.exe retained, and this new script phased in gradually, perhaps as startxwin_new in the first release. Then, when startxwin_new stabilizes, rename the executable to startxwin_old.exe and the script to startxwin. Several updates later, quietly remove startxwin_old.exe. It seems nonsensical to treat all CygwinX users as alpha testers. I'm more than willing to help test new features, but not in the dark: Make it very clear when significant subsystems are being evolved, and provide a way to try the new without losing the old. The changes were announced, and the announcement already sited in this thread. Having read the announcement again, it looks like the replacement has as one of its goals bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. For now, can startxwin.exe be restored under some name? -BobC That part I can't speak to except perhaps to pull it from an old version. I'm not part of the CygwinX team, and have no say in the matter. -- Erik -- 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: startxwin.exe no longer exists?
On 12/16/2014 9:06 AM, Erik Soderquist wrote: snip Shouldn't the startxwin script check for running instances and delete all lock-files related to non-existent instances? Why must this be a manual operation? I generally recommend against automagic cleanup of lock files from dead sessions being a general default because that also wipes out warning that something went wrong. I do it in my situation because I have it on (essentially) dumb terminals where the session working is much more important than knowing something went wrong, and the dumb terminals are on flaky power, so most of the dead sessions are due to power failure anyway. Then the script should provide a popup (via zenity, yad, dialog, or whatever) that informs the user that a prior session crashed, and offer a Continue/Abort choice. Don't force casual X users to learn about lock-files. By default, also provide a popup whenever a running server is detected, to avoid redundant servers being launched inadvertently. Help normal users get on with their work, rather than providing a surprisingly different environment requiring specialized knowledge to resolve. The prior startxwin.exe just worked, and this new replacement script is clearly creating problems for previously happy CygwinX users, where no problems existed before (or, at least the problems weren't visible and didn't affect normal use). I actually have no experience with startxwin; I always called the X server directly with the options I wanted. However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. Evidently, that isn't being done. But the prior startxwin.exe never, in my experience, created the issues of the new startxwin script. I would have preferred to have seen startxwin.exe retained, and this new script phased in gradually, perhaps as startxwin_new in the first release. Then, when startxwin_new stabilizes, rename the executable to startxwin_old.exe and the script to startxwin. Several updates later, quietly remove startxwin_old.exe. It seems nonsensical to treat all CygwinX users as alpha testers. I'm more than willing to help test new features, but not in the dark: Make it very clear when significant subsystems are being evolved, and provide a way to try the new without losing the old. The changes were announced, and the announcement already sited in this thread. Having read the announcement again, it looks like the replacement has as one of its goals bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. I never used this list until AFTER the update killed my previously stable CygwinX environment. It is silly to expect all CygwinX users to actively monitor a list just to avoid getting their systems broken. -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: startxwin.exe no longer exists?
Erik Soderquist wrote: snip Shouldn't the startxwin script check for running instances and delete all lock-files related to non-existent instances? Why must this be a manual operation? I generally recommend against automagic cleanup of lock files from dead sessions being a general default because that also wipes out warning that something went wrong. I do it in my situation because I have it on (essentially) dumb terminals where the session working is much more important than knowing something went wrong, and the dumb terminals are on flaky power, so most of the dead sessions are due to power failure anyway. Apparently not. If I start an X session (using the standard menu item under the start menu) and manually shut it down, the lock file is not deleted. The prior startxwin.exe just worked, and this new replacement script is clearly creating problems for previously happy CygwinX users, where no problems existed before (or, at least the problems weren't visible and didn't affect normal use). Yes, startxwin.exe just worked, and the replacement doesn't. I actually have no experience with startxwin; I always called the X server directly with the options I wanted. What do you mean directly? From a mintty or such? However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. No they're not, unless you restrict kill to mean kill -9 or equivalent. If you kill a process using just kill, or bu shutting it down normally, it should clean up its lock file. I would have preferred to have seen startxwin.exe retained, and this new script phased in gradually, perhaps as startxwin_new in the first release. Then, when startxwin_new stabilizes, rename the executable to startxwin_old.exe and the script to startxwin. Several updates later, quietly remove startxwin_old.exe. It seems nonsensical to treat all CygwinX users as alpha testers. I'm more than willing to help test new features, but not in the dark: Make it very clear when significant subsystems are being evolved, and provide a way to try the new without losing the old. The changes were announced, and the announcement already sited in this thread. Having read the announcement again, it looks like the replacement has as one of its goals bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. Then it's not succeeding. Shutting down X normally under *nix does not result in left-over lock files. -- Will -- 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: startxwin.exe no longer exists?
snip Apparently not. If I start an X session (using the standard menu item under the start menu) and manually shut it down, the lock file is not deleted. On a clean shutdown, the process should clean up its lock files; if it isn't, that needs to looked at and/or reported. The only caveat to that I'm aware of is if a debug flag is set, files the process uses may be intentionally left behind. However, it doesn't sound like you would be setting such flags. snip I actually have no experience with startxwin; I always called the X server directly with the options I wanted. What do you mean directly? From a mintty or such? Windows .bat/.cmd files, custom crafted shortcut on the desktop, windows registry changes... depends on the situation. The one I referenced with the dumb terminals and flaky power is a registry call in autorun starting a .cmd file. However, I can say that freeing of lock files is the job of the process that created the lock files. If you kill the process, stray lock files are a normal expectation. No they're not, unless you restrict kill to mean kill -9 or equivalent. If you kill a process using just kill, or by shutting it down normally, it should clean up its lock file. My apologies; I was only considering kill -9 as 'kill the process'. You are correct, kill -15 is also a kill, but should allow the process to exit cleanly. snip ... bringing the X system more in line with general X and *nix standards, which, as far as I know, has always been a general goal of the entire Cygwin set of projects. Then it's not succeeding. Shutting down X normally under *nix does not result in left-over lock files. I will certainly agree that shutting down X cleanly should not leave stray lock files behind. I can also say that I'm not experiencing that issue. My best guess (and this is only a guess) is that something is causing X to crash as it shuts down on your system, causing the lock files to be left behind. -- Erik -- 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/
