public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Will Parsons <varro@nodomain.invalid> To: cygwin-xfree@cygwin.com Subject: Re: startxwin.exe no longer exists? Date: Tue, 16 Dec 2014 22:58:00 -0000 [thread overview] Message-ID: <slrnm91e8d.15ku.varro@anukis.local> (raw) In-Reply-To: <CACoZoo07+HetoNkknrHUoKYqRL0sRubn98W--FURN0qnXLHDrg@mail.gmail.com> 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/
next prev parent reply other threads:[~2014-12-16 22:58 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-13 16:20 Will Parsons 2014-12-13 18:17 ` Marco Atzeri 2014-12-16 2:50 ` Will Parsons 2014-12-16 2:56 ` Larry Hall (Cygwin-X) 2014-12-16 3:30 ` Will Parsons 2014-12-16 3:35 ` Larry Hall (Cygwin-X) 2014-12-16 14:29 ` Mark Hansen 2014-12-16 16:00 ` Erik Soderquist 2014-12-16 16:36 ` rcunningham 2014-12-16 17:06 ` Erik Soderquist 2014-12-16 17:23 ` rcunningham 2014-12-16 22:58 ` Will Parsons [this message] 2014-12-16 23:39 ` Erik Soderquist 2014-12-17 17:29 ` mathog 2014-12-17 17:40 ` Erik Soderquist 2014-12-17 17:52 ` mathog 2014-12-17 18:36 ` Erik Soderquist 2014-12-17 19:02 ` mathog
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=slrnm91e8d.15ku.varro@anukis.local \ --to=varro@nodomain.invalid \ --cc=cygwin-xfree@cygwin.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).