From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28487 invoked from network); 31 Jul 2021 22:21:04 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2021 22:21:04 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0BF819CB59; Sun, 1 Aug 2021 08:20:48 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 578659CA91; Sun, 1 Aug 2021 08:20:21 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=iitbombay-org.20150623.gappssmtp.com header.i=@iitbombay-org.20150623.gappssmtp.com header.b="MdAapb69"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3C9829CAF5; Sun, 1 Aug 2021 08:20:20 +1000 (AEST) Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by minnie.tuhs.org (Postfix) with ESMTPS id E78929CAA1 for ; Sun, 1 Aug 2021 08:20:17 +1000 (AEST) Received: by mail-oo1-f50.google.com with SMTP id h7-20020a4ab4470000b0290263c143bcb2so3458899ooo.7 for ; Sat, 31 Jul 2021 15:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y007ye9eCUUSqmWkod1Gv06g6eJQrJBtv06jgDEV/u0=; b=MdAapb69cefnGU0lgU5jC/OS4ar+RqOGXmcuTWuWdFJwf9umAq8rNlV72WSt4W/OzB 6z8M9cEKWXQt7+MGvQz5ioCiVuVb5uG/T4MPxzJM8hQrkf5UA1mpyCH1zbYqx5glcX6n sw2J9H1LuDle2m+ihnv1bY1z7RB4Hmu6gUtlilHAAoJ4ZM9AwqTKa9PDgo57hdBHKg9z RSi+W/SkQMiCDUU77uDHSd7cZeWu3USaAffAhh/0ZQmSS6TMPZFkYSr5iwSEFm46boCz IF1k3jbxMQfNMMFwRgNS2AFvwwD8Ttyxni73sffZ6Rq3p4vndH+w0EYWnsw/xmrNvUAR Jblg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y007ye9eCUUSqmWkod1Gv06g6eJQrJBtv06jgDEV/u0=; b=FJU5DBrpgi0zeq8Fp2PMtkntXiwiG9znz9x9rYt3A8zx8hSie7Eu3X5/kop61RiFGN iq0TDPmllGMf2jP4vMy3c8/+EowaoAJ2SrDzXCvJNaXaRsR+Us5d5XexzMdtV1we6UHl 6/8BqNgbrl06sGpmD530w9SrmbWyMuVs9XG0bsIqb/FvUR7LPvS+/4orMTQKgDJ9mGee nKlea1Ao2t4VeF6PgCLmSCrc5tB/+4We8exUctQ5E5mVd+eGUfsuPgbWsOWxS0AqT/Jn hwBTjY54CbcbwjeGLyvmGvzHWqZN/DWRxCG0iaYAeUNuUZtXxmhGq6FWODCOPmmENYH9 BFzA== X-Gm-Message-State: AOAM532VPrYqNzdSMUVuymY66LFJhM1VBoTWqcpXGUwaRfA4J7V9itXU JydXDXOTP58bo7dAul4dVis/Ov5b/NL4n19z X-Google-Smtp-Source: ABdhPJyP8p+lLjyJlThlhG1izpK+D8Xf3rRU2omwMuQ7jxk4OxoPk3G8BUXFfhfdYfjEvDDcTLod3w== X-Received: by 2002:a4a:df41:: with SMTP id j1mr6144246oou.25.1627770017135; Sat, 31 Jul 2021 15:20:17 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id e125sm1015299oia.0.2021.07.31.15.20.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Jul 2021 15:20:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Bakul Shah In-Reply-To: <202107312216.16VMGwTX2446561@fourwinds.com> Date: Sat, 31 Jul 2021 15:20:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210731142533.69caf929@moon> <202107311920.16VJK2jT2362871@fourwinds.com> <3598EE71-E652-43EF-B1AB-91CB8B3D577A@iitbombay.org> <202107312216.16VMGwTX2446561@fourwinds.com> To: Jon Steinhart X-Mailer: Apple Mail (2.3654.120.0.1.13) Subject: Re: [TUHS] Systematic approach to command-line interfaces [ meta issues ] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" -- Bakul > On Jul 31, 2021, at 3:16 PM, Jon Steinhart wrote: >=20 > Bakul Shah writes: >> On Jul 31, 2021, at 12:20 PM, Jon Steinhart = wrote: >>>=20 >>> So I never got getopt(). One of my rules is that I don't use a = library >>> in cases where the number of lines of gunk that that it takes to use = a >>> library function is >=3D the number of lines to just write it = myself. Yeah, >>> I know the "but the library has more eyeballs and is debugged" = argument >>> but in reality libraries are the source of many bugs. I've always = taken >>> the approach that I would never hire someone who had to use a = library to >>> implement a singly-linked list. >>=20 >> getopt() is perhaps the wrong solution but consider something like = MH, >> whose commands all follow a common pattern. Consider: >>=20 >> - options (switches) all start with a single '-' >> - they may be abbreviated to a unique prefix. >> - Boolean options may be inverted by prepending -no (e.g. -nolist) >> - value options may also have -no format to remove a previous (or = default) value >> - options may appear anywhere and the last instance wins >>=20 >> But different commands take different options. It would make sense to = factor >> out common parsing, help etc. for a consistent treatment. In my Go = code for >> parsing MH like options I used Go's flag package as a model. >>=20 >> Personally I vastly prefer MH style option processing to either = single char >> options or --very-long-names which can't be abbreviated. Never mind = options for >> commands like gcc, who can even remember 40+ ls options? >>=20 >> But I haven't thought about how to extend this for shell scripts, or >> exposing these so that shells like zsh can do command completion. To = specify >> these you need a vector of tuples (name, type, default, brief-help) = but that >> is painful to do in a shell. >=20 > Ah, well, you've given away the secret of real UNIX geezers, we're on = both > this mailing list and the nmh list :-) :-) > Yes, I'm mostly happy with the way that nmh does options. >=20 > I guess that I would look more kindly on getopt if it had existed much = earlier > so that people writing new commands would be encouraged to use the = same format. > Not as happy with it as an afterthought. >=20 > Once again, I have to go back to the meatspace locality of reference = issues. > Sure, it would be nice to be able to factor out common parsing, for = example > if a related set of programs shared the same option set. But unless = it's > something huge, I'd just put it in it's own file and use it for = multiple > programs; I wouldn't put it in a library. My point is that the code = that > does the actual parsing is really trivial, and not necessarily the = best > use of a library. >=20 > As far as help goes, I don't expect help built into command line = programs; > I expect to look up error messages on the manual pages. I'm happy = with a > generic usage error as most "helpful" output that I get from programs = is > not actually helpful. Note that -help in MH program is far more useful as it spells out the = full option name. Consider % refile -he Usage: refile [msgs] [switches] +folder ... switches are: -draft -[no]link -[no]preserve -[no]retainsequences -[no]unlink -src +folder -file file -rmmproc program -normmproc -version -help ... vs % ls -z ls: invalid option -- z usage: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,] [--color=3Dwhen] = [-D format] [file ...]