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/