From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lucy.dinwoodie.org (77.116.2.81.in-addr.arpa [81.2.116.77]) by sourceware.org (Postfix) with ESMTPS id B7E823858C83 for ; Tue, 1 Feb 2022 21:46:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7E823858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dinwoodie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dinwoodie.org Received: from adam by lucy.dinwoodie.org with local (Exim 4.94.2) (envelope-from ) id 1nF0yn-0006MQ-Ey for cygwin@cygwin.com; Tue, 01 Feb 2022 21:46:25 +0000 Date: Tue, 1 Feb 2022 21:46:25 +0000 From: Adam Dinwoodie To: cygwin@cygwin.com Subject: Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)] Message-ID: <20220201214624.54i47ai3l2yfdhir@lucy.dinwoodie.org> References: <20220131221159.3hcw3xxcwje6sahf@lucy.dinwoodie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, PDS_RDNS_DYNAMIC_FP, RDNS_DYNAMIC, SPAM_BODY, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 21:46:28 -0000 On Tue, Feb 01, 2022 at 04:53:47PM +0000, Jon Turney wrote: > On 31/01/2022 22:11, Adam Dinwoodie wrote: > > On Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote: > > > On 2022-01-31 08:46, Andrey Repin wrote: > > > > Greetings, Jon Turney! > > > > > > > > > Probably what's wanted is to remember the state of those checkboxes, if > > > > > this isn't the first time setup has been run? > > > > > > > > That's a feature silently longed for for a loong time. :) But this is such a > > > > low priority, very few people actually mentioned it in the past years. > > > > > > It could usefully be added similarly to last-action: > > > > > > $ fgrep -A1 action /etc/setup/setup.rc > > > last-action > > > Download,Install > > > > > > last-shortcut: > > > Desktop|StartMenu|none,... > > > > This reminded me of a bug report I've been meaning to properly > > characterise and report for a while, and also pointed me at a > > workaround... > > > > Currently, running `setup-*.exe --help` produces output that includes > > the following: > > > > -D --download Download packages from internet only > > -L --local-install Install packages from local directory only > > > > The default is to both download and install packages, unless either > > --download or --local-install is specified. > > > > I think the descriptions for the `-D` and `-L` options are misleading, > > at least in combination with that final line, which is definitely wrong. > > As I understand it, the actual behaviour would be better described by > > something like the below: > > > > -D --download Download packages from internet only, unless -L > > is also specified > > -L --local-install Install packages from local directory only, > > unless -D is also specified > > One could just remove the word 'only'? ...yes, that would in fact work, and is clear. > > If neither --download nor --local-install is specified, the default > > is to repeat the same action as from the previous run. If no > > previous run can be found, the default is to perform both actions, > > and both actions can be explicitly requested by specifying both > > --download and --local-install. > > Note that I tweaked the behaviour of this a bit in [1] > > [1] https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commit;h=147fc15d0222e050779b18a209991c258d85944f > > I think that makes the current help text accurately describe non-interactive > mode. > > There are some cases in interactive mode which are obscure (e.g. '-M' > without '-D' or '-L' gets you whatever mode you used last time without > showing you what it was, but I'm not sure if that needs to be here. Ah, okay. I think I hit this with `-M` and assumed -- evidently incorrectly -- that the same behaviour would exist for `-q`. I agree the current text is entirely accurate for the fully non-interactive mode. I think this caught me out because I frequently run with `-M` -- I don't care about most of the options, but I do want to see what packages are about to be updated -- and I almost never want to use the download-only or install-only modes. But I used `-L` as a one-off when I was uninstalling and reinstalling a bunch of packages and didn't want to hit the network every time, then forgot about it. And it wasn't until I was musing about the fact that I hadn't seen any package updates for a few weeks when trying to do my regular updates with `-M` that I realised what had happened... Given all that, I think everything seems sensible except for the fact that `-M` doesn't follow the same behaviour as `-q`. > > In particular, the fact that the two options currently say they will > > "only" do their action, and that the default is to perform both, lead me > > to believe (a) the options were mutually exclusive and one would > > presumably override the other, (b) this was probably a legacy from > > before setup.rc stored the previous action, and therefore (c) if I was > > running setup with `-q` or `-M`, there was no way to get the supposedly > > default "do both" behaviour; I'd instead need to go through the full > > GUI. > > > > Having now seen how this setting is stored, I've realised I can just > > call setup with `-DL` and it'll perform both actions again. But I think > > my assumption that "default" was supposed to mean "default always" not > > "default only on first run" wasn't *entirely* PEBCAK (even if it mostly > > was), so that help text would definitely benefit from being made a bit > > more explicit. > > > > (I'm aware my suggestion above is decidedly wordy; it's not intended to > > be exactly what I think is required, only a first pass at clarifying the > > key details I think are missing.) > > Perhaps the best thing would be to have something like '--mode={download, > install, somebetterwordforboth}' and document '-D' and '-L' as short aliases > for forms of that (which makes the modality clear). I definitely see no harm in that approach, and I agreed that'd make things clearer again. But, as above, I think the key thing from my perspective would be for `-M` and `-q` to have consistent behaviour.