The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: "John P. Linderman" <jpl.jpl@gmail.com>
Cc: The Unix Heritage Society <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Command line options and complexity
Date: Thu, 12 Mar 2020 20:24:38 +0100	[thread overview]
Message-ID: <20200312192438.q9Q4k%steffen@sdaoden.eu> (raw)
In-Reply-To: <CAC0cEp_fQsq6-EaG-nhvXTvZij+PSab5PNTEx7WhNjYwnFVnaw@mail.gmail.com>

John P. Linderman wrote in
<CAC0cEp_fQsq6-EaG-nhvXTvZij+PSab5PNTEx7WhNjYwnFVnaw@mail.gmail.com>:
 |My error. I was looking at getopt(1) rather than getopt(3). Of course \
 |optind is documented, it's the way to find non-flag arguments.

 |I don't know why the Hancock authors chose to make rsort into a subroutine \
 |rather than just piping into the command. Perhaps something to do with \
 |the software release process?

I really like a lot of such old code, and reading it.  One can
only learn from it.  Even though i discovered all this in
(Free)BSD land, after coming over from Linux, I loved reading
those "old-hand" comment blocks, it was inspiration and kindled
something here.  For the few pieces of code that i am prowd of aka
that i thought were worth it i followed their example.  This
rsort.c is however more verbose and spiritful than anything i ever
wrote.  I keep it in my box of precious things.

getopt(3) on the other hand is portable but terrible.  Just on the
10th i resorted a small SCSI MMC-3 cdda access tool (~50 KB
C source are necessary for that in 2020, missing Solaris and
MacOS, but including CD-TEXT and all that!!) to it because people
are used to option and/or argument joining etc, but it lost long
option support.

Not worth commenting a lot, but here is an option parser of 6359
bytes when development verification code and dump_doc() are not
counted, but is uses a carrier struct, supports long options, and
documentation strings as part of long option strings (one .RODATA
entry).  FreeBSD's standard compatible and thus naked
lib/libc/stdlib/getopt.c is 4312 bytes.  And GNU's getopt_long is
huge and even permutates arguments.

At least getopt(3) is predictable once a user gets it.  Things are
different for sed(1)s -i and some sccs commands i have forgotten.
I think it has even be tried to standardize optional arguments in
that respect, but i would argue this is not a good direction to
go, consider for example "sed -ie".  Isn't this asking for
troubles without accompanying comments.

 *   static char const a_sopts[] = "A:h#";
 *   static char const * const a_lopts[] = {
 *      "account:;A;" N_("execute an `account' command"),
..
 *      "long-help;\201;" N_("this listing"),
 *      NIL
 *   };
..
 *   struct su_avopt avo;
..
 *   su_avopt_setup(&avo, --argc, C(char const*const*,++argv),
 *      a_sopts, a_lopts);
 *   while((i = su_avopt_parse(&avo)) != su_AVOPT_STATE_DONE){
 *      switch(i){
 *      case 'A':
 *         "account_name" = avo.avo_current_arg;
 *         break;
 *      case 'h':
 *      case S(char,S(u8,'\201')):
 *         a_main_usage(n_stdout);
 *         if(i != 'h'){
 *            fprintf(n_stdout, "\nLong options:\n");
 *            su_avopt_dump_doc(&avo, &a_main_dump_doc, S(up,n_stdout));
 *         }
 *         exit(0);
..
 *   argc = avo.avo_argc;
 *   argv = C(char**,avo.avo_argv);

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  reply	other threads:[~2020-03-12 19:25 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-04 14:06 Nelson H. F. Beebe
2020-03-04 16:17 ` John P. Linderman
2020-03-04 17:25   ` Bakul Shah
2020-03-05  0:55   ` Rob Pike
2020-03-05  2:05   ` Kurt H Maier
2020-03-05  4:17     ` Ken Thompson via TUHS
2020-03-05 14:53       ` Dan Cross
2020-03-05 21:50       ` Dave Horsfall
2020-03-05 21:56         ` Warner Losh
2020-03-08  5:26           ` Greg 'groggy' Lehey
2020-03-08  5:32             ` Jon Steinhart
2020-03-08  9:30               ` Tyler Adams
     [not found]                 ` <CAC0cEp8eFRkkLTw88WVaKZoKy+qsrhuC8LkzmmsbqtdZgMf8eQ@mail.gmail.com>
     [not found]                   ` <CAEuQd1D7+dfap98AwPo2W41+06prrcVaAWk3Ve-ve0uQ0xBu3Q@mail.gmail.com>
2020-03-09 21:06                     ` John P. Linderman
2020-03-09 21:22                       ` Kurt H Maier
2020-03-11 17:41                         ` John P. Linderman
2020-03-11 21:29                           ` Warner Losh
2020-03-12  0:13                             ` John P. Linderman
2020-03-12  0:34                               ` Chet Ramey
2020-03-12 12:57                             ` John P. Linderman
2020-03-12 19:24                               ` Steffen Nurpmeso [this message]
2020-03-08  9:51             ` Michael Kjörling
  -- strict thread matches above, loose matches on Subject: below --
2020-03-13 10:45 Dave Horsfall
2020-03-14  4:35 ` Greg 'groggy' Lehey
2020-03-14 19:52   ` John P. Linderman
2020-03-14 20:25     ` Steffen Nurpmeso
2020-03-10 18:42 Doug McIlroy
2020-03-10 19:38 ` Dan Cross
2020-03-10 16:15 Doug McIlroy
2020-03-10 17:38 ` Dan Cross
2020-03-10 17:44   ` Bakul Shah
2020-03-10 18:09     ` Dan Cross
2020-03-05  4:57 Doug McIlroy
2020-03-05 22:17 ` Diomidis Spinellis
2020-03-03 18:15 Jon Steinhart
2020-03-03 18:44 ` Adam Thornton
2020-03-04  4:11   ` Tyler Adams
2020-03-04  6:03     ` Dave Horsfall
2020-03-04  6:48       ` arnold
2020-03-04 21:17         ` Dave Horsfall
2020-03-05  0:49         ` Lyndon Nerenberg
2020-03-05 20:54           ` Dave Horsfall
2020-03-05 22:01             ` William Cheswick
2020-03-04 21:50   ` Random832
2020-03-04 23:19     ` Steffen Nurpmeso
2020-03-05  6:12     ` Alan D. Salewski
2020-03-04 22:03   ` Random832
2020-03-04 23:25     ` Terry Jones
2020-03-10 23:03 ` Dan Stromberg
2020-03-11  3:18   ` Dave Horsfall
2020-03-11  4:02     ` Steve Nickolas
2020-03-11 22:56     ` Greg 'groggy' Lehey
2020-03-11 23:14       ` Dan Cross
2020-03-12  0:42         ` Greg 'groggy' Lehey
2020-03-12  0:53       ` Steve Nickolas
2020-03-12  3:09         ` Greg 'groggy' Lehey
2020-03-12  3:34           ` Steve Nickolas
2020-03-13  1:02             ` Greg 'groggy' Lehey
2020-03-12  5:38         ` Dave Horsfall
2020-03-12  6:48         ` Peter Jeremy
2020-03-12  7:37           ` Steve Nickolas
2020-03-12  7:42             ` Warner Losh
2020-03-12 23:57           ` Greg 'groggy' Lehey
2020-03-12  5:22       ` Dave Horsfall
2020-03-12  5:35         ` Steve Nickolas
2020-03-13  0:36         ` Greg 'groggy' Lehey
2020-03-13 11:26           ` Dave Horsfall
2020-03-14  2:13           ` Greg A. Woods
2020-03-14  4:31             ` Greg 'groggy' Lehey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200312192438.q9Q4k%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=jpl.jpl@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).