From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18893 invoked by alias); 16 Dec 2014 22:58:44 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 18842 invoked by uid 89); 16 Dec 2014 22:58:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 16 Dec 2014 22:58:41 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y114c-0003Cu-Cj for cygwin-xfree@cygwin.com; Tue, 16 Dec 2014 23:58:34 +0100 Received: from 65.75.36.70 ([65.75.36.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Dec 2014 23:58:34 +0100 Received: from gyliamos by 65.75.36.70 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Dec 2014 23:58:34 +0100 To: cygwin-xfree@cygwin.com From: Will Parsons Subject: Re: startxwin.exe no longer exists? Date: Tue, 16 Dec 2014 22:58:00 -0000 Message-ID: References: <548C82A3.9080604@gmail.com> <54905E8F.40809@ucsd.edu> Reply-To: gyliamos@gmail.com User-Agent: slrn/1.0.1 (FreeBSD) X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00041.txt.bz2 Erik Soderquist wrote: > > >> 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/