From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1555 invoked by alias); 16 Dec 2014 17:06:22 -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 1542 invoked by uid 89); 16 Dec 2014 17:06:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f46.google.com Received: from mail-yh0-f46.google.com (HELO mail-yh0-f46.google.com) (209.85.213.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 16 Dec 2014 17:06:20 +0000 Received: by mail-yh0-f46.google.com with SMTP id t59so6310882yho.33 for ; Tue, 16 Dec 2014 09:06:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.236.30.65 with SMTP id j41mr27363046yha.105.1418749578670; Tue, 16 Dec 2014 09:06:18 -0800 (PST) Received: by 10.170.233.6 with HTTP; Tue, 16 Dec 2014 09:06:18 -0800 (PST) In-Reply-To: <54905E8F.40809@ucsd.edu> References: <548C82A3.9080604@gmail.com> <54905E8F.40809@ucsd.edu> Date: Tue, 16 Dec 2014 17:06:00 -0000 Message-ID: Subject: Re: startxwin.exe no longer exists? From: Erik Soderquist To: cygwin-xfree@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00039.txt.bz2 > 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/