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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8321 invoked from network); 31 Jul 2021 14:25:53 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2021 14:25:53 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 292F89C9EA; Sun, 1 Aug 2021 00:25:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A61509C9B2; Sun, 1 Aug 2021 00:25:40 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="N65cxw5R"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1FA9A9C9B2; Sun, 1 Aug 2021 00:25:38 +1000 (AEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by minnie.tuhs.org (Postfix) with ESMTPS id F01119C9AF for ; Sun, 1 Aug 2021 00:25:36 +1000 (AEST) Received: by mail-pj1-f41.google.com with SMTP id ds11-20020a17090b08cbb0290172f971883bso25059181pjb.1 for ; Sat, 31 Jul 2021 07:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JRlZNvnfA+7ztYKiU6xXu09JyGTvEfFk6mOuwbx3S7U=; b=N65cxw5Rdm0EL3zdAE6LehIhKuV3/YYXuzYMTUOPqQRIujYwxwwRaxTY4eHAyEakgi CIBQTU33FNiHQRvKJ118qTVjehWVbZ5BIM1kb2t9aJKK117ItcWLr6orUg1isngiOmJr q/IjRJFgCdQBo1v5jo9xj5k8DdiM/CK3+n0vGMxAWT0h+C4C99zwaKT7NxCYAHi9XlU6 ow6zBK5e1O1J+vemBRPSk/UJeXgAy2i4G0PBUpj+9m0VPyxHQYeeLg95Ox5AWczpM85W kdIyGuPsLG7W40f1AX0oMR4TcF+zG1fS3jIQmH+lbRj8As8ircA8vXPE6dF5fM9MEn+2 00wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JRlZNvnfA+7ztYKiU6xXu09JyGTvEfFk6mOuwbx3S7U=; b=YPNoPygMwFJgOvvZnG/iRACNkPhRLXxIWkiXL/TiX28cBZgCYInZTEYjztu/580AlL xOo6l4ot8tnLvz4l1dfDY0uT83hvj85cQugt88K/lIWNCVbV1656iyntLz2xTVTH7evA AOu/JqaVAXuskod4shN9COl6sfZy7q80IapztYyOHM9tQP6XHy5r9w6S51LrVlHHPIKw prMkgiJH/e9YFNF5PrFs6oG3/SzdqU6QNFZERznX6ulxyjN3iT9kw5NEYJn7IAqBxZ8j gATaMXvxJWIrDmbxfNByU4Iw/fJfDS0B7GF5p4hgZVxcEai9i/JEUMjzlWW+fiGgY8/8 yfCA== X-Gm-Message-State: AOAM530LeFrij7VuguNzos336VvBjrMqpzkM3cVWP5bk/r5ijm7gHoLg ecmHF1kjZoKDE25YSO/Lt97CuHECqOlsShwRZVFLW6gTmkM= X-Google-Smtp-Source: ABdhPJwcosLWK/01lyeuKl49j+8N9Fq5n+wqYyMS/XQTOWTnl+WFFqs7ZS9GybHgSHQgUmqN6mQwYsM7CaIazVvRyyE= X-Received: by 2002:aa7:808b:0:b029:3a9:c8c1:3e3a with SMTP id v11-20020aa7808b0000b02903a9c8c13e3amr8105437pff.16.1627741536141; Sat, 31 Jul 2021 07:25:36 -0700 (PDT) MIME-Version: 1.0 References: <20210731142533.69caf929@moon> In-Reply-To: From: Adam Thornton Date: Sat, 31 Jul 2021 07:25:24 -0700 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="0000000000000c44e705c86c1c44" Subject: Re: [TUHS] Systematic approach to command-line interfaces 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000000c44e705c86c1c44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Digressing a bit (but only a bit) talking about IPC: Powershell and CMS PIPELINES both take the approach of more structured pipelines, where pipe contents are not just streams of bytes but can be structured records. This offers a lot of power, but it also inhibits the ability to arbitrarily compose pipe stages, because you've effectively introduced a type system. On the other hand you can certainly argue that stream-of-bytes pipes ALSO introduce a type system, it's just a completely ad-hoc, undocumented, and fragile one that relies on the cooperation of both ends of the pipe to work at all, and you'd be right. In practice...well, I'd rather use stream-of-bytes, but I am more comfortable in Unix-like environments than Powershell, and my CMS PIPELINES skills are quite rusty now. On Sat, Jul 31, 2021 at 7:21 AM Adam Thornton wrote: > > > On Jul 31, 2021, at 5:25 AM, Michael Siegel wrote: > > While doing that, I learned that there is a better way to approach > this problem =E2=80=93 beyond using getopt(s) (which never really made se= nse to > me) and having to write case statements in loops every time: Define a > grammar, let a pre-built parser do the work, and have the parser > provide the results to the program. > > > I see that Dan Halbert beat me to mentioning "click." > > The trick with shell is that unless you write the parser in shell, which > is going to be miserable, you=E2=80=99re doing it in a command in a subsh= ell, and > therefore your return values have to be a structured stream of bytes on > stdout, which the parent shell is going to have to interpret. An eval-ab= le > shell fragment, where you have a convention of what the variables you get > from the option parser will be, is probably the easiest way, since from t= he > parent that would look like: > > $(parse_my_opts $*) > # Magic variables spring to life > if [ =E2=80=9C$OPT_SUBCOMMAND_0=E2=80=9D =3D=3D =E2=80=9Cburninate=E2=80= =9D ]; then =E2=80=A6. > > Adam > --0000000000000c44e705c86c1c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Digressing a bit (but only a bit) talking about IPC: = Powershell and CMS PIPELINES both take the approach of more structured pipe= lines, where pipe contents are not just streams of bytes but can be structu= red records.=C2=A0 This offers a lot of power, but it also inhibits the abi= lity to arbitrarily compose pipe stages, because you've effectively int= roduced a type system.

On the other hand you can c= ertainly argue that stream-of-bytes pipes ALSO introduce a type system, it&= #39;s just a completely ad-hoc, undocumented, and fragile one that relies o= n the cooperation of both ends of the pipe to work at all, and you'd be= right.

In practice...well, I'd rather use str= eam-of-bytes, but I am more comfortable in Unix-like environments than Powe= rshell, and my CMS PIPELINES skills are quite rusty now.
On Sat, J= ul 31, 2021 at 7:21 AM Adam Thornton <athornton@gmail.com> wrote:


On Jul 31, 2021, at 5:25 AM, Michael Siegel <msi@malbolge.net> wrote:

While doing that, I learned that there is a better way to= approach
this problem =E2=80=93 beyond using getopt(s) (which never rea= lly made sense to
me) and having to write case statements in loops every= time: Define a
grammar, let a pre-built parser do the work, and have th= e parser
provide the results to the program.

I see that Dan Halbert beat me to mentioning "click.&q= uot;

The trick with shell is that unless you w= rite the parser in shell, which is going to be miserable, you=E2=80=99re do= ing it in a command in a subshell, and therefore your return values have to= be a structured stream of bytes on stdout, which the parent shell is going= to have to interpret.=C2=A0 An eval-able shell fragment, where you have a = convention of what the variables you get from the option parser will be, is= probably the easiest way, since from the parent that would look like:

$(parse_my_opts $*)
# Magic variables spring= to life
if [ =E2=80=9C$OPT_SUBCOMMAND_0=E2=80=9D =3D=3D =E2=80= =9Cburninate=E2=80=9D ]; then =E2=80=A6.

Adam
--0000000000000c44e705c86c1c44--