The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Systematic approach to command-line interfaces
@ 2021-07-31 12:25 Michael Siegel
  2021-07-31 13:05 ` Dan Halbert
                   ` (6 more replies)
  0 siblings, 7 replies; 100+ messages in thread
From: Michael Siegel @ 2021-07-31 12:25 UTC (permalink / raw)
  To: tuhs

Hello,

I've recently started to implement a set of helper functions and
procedures for parsing Unix-like command-line interfaces (i.e., POSIX +
GNU-style long options, in this case) in Ada.

While doing that, I learned that there is a better way to approach
this problem – beyond using getopt(s) (which never really 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 the parser
provide the results to the program.

Now, defining such a grammar requires a thoroughly systematic approach
to the design of command-line interfaces. One problem with that is
whether that grammar should allow for sub-commands. And that leads to
the question of how task-specific tool sets should be designed. These
seem to be a relatively new phenomenon in Unix-like systems that POSIX
doesn't say anything about, as far as I can see.

So, I've prepared a bit of a write-up, pondering on the pros and cons
of two different ways of having task-specific tool sets
(non-hierarchical command sets vs. sub-commands) that is available at

  https://www.msiism.org/files/doc/unix-like_command-line_interfaces.html

I tend to think the sub-command approach is better. But I'm neither a UI
nor a Unix expert and have no formal training in computer things. So, I
thought this would be a good place to ask for comment (and get some
historical perspective).

This is all just my pro-hobbyist attempt to make some people's lives
easier, especially mine. I mean, currently, the "Unix" command line is
quite a zoo, and not in a positive sense. Also, the number of
well-thought-out command-line interfaces doesn't seem to be a growing
one. But I guess that could be changed by providing truly easy ways to
make good interfaces.


--
Michael

^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-07-31 16:27 Nelson H. F. Beebe
  0 siblings, 0 replies; 100+ messages in thread
From: Nelson H. F. Beebe @ 2021-07-31 16:27 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

Besides C-Kermit on Unix systems, the TOPS-20 command interface is
used inside the mm mail client, which I've been using for decades on
TOPS-20, VMS, and several flavors of Unix:

	http://www.math.utah.edu/pub/mm

mm doesn't handle attachments, or do fancy display of HTML, and thus,
cannot do anything nasty in response to incoming mail messages.

I rarely need to extract an attachment, and I then save the message in
a temporary file and run munpack on it.

Here are some small snippets of its inline help:

    MM] read (messages) ? message number
      or range of message numbers, n:m
      or range of message numbers, n-m
      or range of message numbers, n+m (m messages beginning with n)
      or "." to specify the current message
      or "*" to specify the last message
      or message sequence, one of the following:
     after               all                 answered            before
     current             deleted             flagged             from
     inverse             keyword             last                longer
     new                 on                  previous-sequence   recent
     seen                shorter             since               subject
     text                to                  unanswered          undeleted
     unflagged           unkeyword           unseen              
      or "," and another message sequence

    R] read (messages) flagged since yesterday
    [message(s) appear here]

    MM] headers (messages) since monday longer (than) 100000
    [list of long messages here]

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-07-31 16:47 Ron Young
  2021-08-02  2:34 ` Jim Carpenter
  0 siblings, 1 reply; 100+ messages in thread
From: Ron Young @ 2021-07-31 16:47 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

 > On 7/31/21, Michael Siegel <msi@malbolge.net> wrote:

 > The TOPS-20 COMND JSYS implemented both of these features, and I 
think that command
 > completion was eventually added to the VMS command interpreter, too.

FYI, There is also a unix version of the COMND JSYS capability. It was 
developed at Columbia University as part of their "mm" mail manager. It 
is located in to the ccmd subdirectory in the mm.tar.gz file.

url: https://www.kermitproject.org/mm/

ftp://ftp.kermitproject.org/kermit/mm/mm.tar.gz

-ron


^ permalink raw reply	[flat|nested] 100+ messages in thread
* [TUHS] Systematic approach to command-line interfaces
@ 2021-08-02  2:42 Douglas McIlroy
  2021-08-02 14:58 ` Theodore Ts'o
  0 siblings, 1 reply; 100+ messages in thread
From: Douglas McIlroy @ 2021-08-02  2:42 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> spawn() beats fork()[;] fork() should be deprecated

Spawn is a further complication of exec, which tells what signals and
file descriptors to inherit in addition to what arguments and
environment variables to pass.

Fork has a place. For example, Program 1 in
www.cs.dartmouth.edu/~doug/sieve/sieve.pdf forks like crazy and never
execs. To use spawn, the program would have to be split in three (or
be passed a switch setting).

While you may dismiss Program 1 as merely a neat demo, the same idea
applies in parallelizing code for use in a multiprocessor world.

Doug

^ permalink raw reply	[flat|nested] 100+ messages in thread
* [TUHS] Systematic approach to command-line interfaces
@ 2021-08-03 15:01 Douglas McIlroy
  2021-08-03 17:13 ` Tom Lyon via TUHS
  0 siblings, 1 reply; 100+ messages in thread
From: Douglas McIlroy @ 2021-08-03 15:01 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> fork() is a great model for a single-threaded text processing pipeline to do
> automated typesetting.  (More generally, anything that is a straightforward
>  composition of filter/transform stages.)  Which is, y'know, what Unix is *for*.

> It's not so great for a responsive GUI in front of a multi-function interactive  program.

"Single-threaded" is not a term I would apply to multiple processes in
a  pipeline. If you mean a single track of data flow, fine, but the
fact that that's a prevalent configuration of cooperating processes in
Unix is an artifact of shell syntax, not an inherent property of
pipe-style IPC. The cooperating processes in Rob Pike's 20th century
window systems and screen editors, for example, worked smoothly
without interrupts or events - only stream connections. I see no
abstract distinction between these programs and  "stuff people play
with on their phones."

It bears repeating, too, that stream connections are much easier to
reason about than asynchronous communication. Thus code built on
streams is far less vulnerable to timing bugs.

At last a prince has come to awaken the sleeping beauty of stream
connections. In  Go (Pike again) we have a widely accepted programming
language that can fully exploit them, "[w]hich is, y'know, what Unix
is 'for'."

(If you wish, you may read "process" above to include threads, but
I'll stay out of that.)

Doug

^ permalink raw reply	[flat|nested] 100+ messages in thread
* [TUHS] Systematic approach to command-line interfaces
@ 2021-08-03 19:12 Douglas McIlroy
  0 siblings, 0 replies; 100+ messages in thread
From: Douglas McIlroy @ 2021-08-03 19:12 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> Go gets us part of the way there, but cross-machine messaging is still a mess.

Shed a tear for Plan 9 (Pike yet again). While many of its secondary
innovations have been stuffed into Linux; its animating
principle--transparently distributable computing--could not overcome
the enormous inertia of installed BSD-model systems.

Doug

^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-09-28 18:15 Noel Chiappa
  0 siblings, 0 replies; 100+ messages in thread
From: Noel Chiappa @ 2021-09-28 18:15 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: "Greg A. Woods"

    > the elegance of fork() is incredible!

That's because in PDP-11 Unix, they didn't have the _room_ to create a huge
mess. Try reading the exec() code in V6 or so.

(I'm in a bit of a foul mood today; my laptop sorta locked up when a _single_
Edge browser window process grew to almost _2GB_ in size. Are you effing
kidding me? If I had any idea what today would look like, back when I was 20 -
especially the massive excrement pile that the Internet has turned into - I
never would have gone into computers - cabinetwork, or something, would have
been an infinitely superior career choice.)

    > I now struggle with liking the the Unix concept of "everything is a
    > file" -- especially with respect to actual data files.  Multics also got
    > it right to use single-level storage -- that's the right abstraction

Well, files a la Unix, instead of the SLS, are OK for a _lot_ of data storage
- pretty much everything except less-common cases like concurrent access to a
shared database, etc.

Where the SLS really shines is _code_ - being able to just do a subroutine
call to interact with something else has incredible bang/buck ratio - although
I concede doing it all securely is hard (although they did make a lot of
progress there).

	 Noel


^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-09-29 18:07 Noel Chiappa
  2021-09-29 19:04 ` Dan Cross
  2021-09-29 19:12 ` Larry McVoy
  0 siblings, 2 replies; 100+ messages in thread
From: Noel Chiappa @ 2021-09-29 18:07 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Larry McVoy

    > If you read(2) a page and mmap()ed it and then did a write(2) to the
    > page, the mapped page is the same physical memory as the write()ed
    > page. Zero coherency issues.

Now I'm confused; read() and write() semantically include a copy operation
(so there are then two copies of that data chunk, and possible consistency
issues between them), and the copied item is not necessarily page-sized (so
you can't ensure consistency between the original+copy by mapping it in). So
when one does a read(file, &buffer, 1), one gets a _copy of just that byte_
in the process' address space (and similar for write()).

Yes, there's no coherency issue between the contents of an mmap()'d page, and
the system's idea of what's in that page of the file, but that's a
_different_ coherency issue.

Or am I confused?


PS:
    > From: "Greg A. Woods"

    > I now struggle with liking the the Unix concept of "everything is a
    > file" -- especially with respect to actual data files.  Multics also got
    > it right to use single-level storage -- that's the right abstraction

Oh, one other thing that SLS breaks, for data files, is the whole Unix 'pipe'
abstraction, which is at the heart of the whole Unix tools paradigm. So no
more 'cmd | wc' et al. And since SLS doesn't have the 'make a copy'
semantics of pipe output, it would be hard to trivially work around it.

Yes, one could build up a similar framework, but each command would have to
specify an input file and an output file (no more 'standard in' and 'out'),
and then the command interpreter would have to i) take command A's output file
and feed it to command B, and ii) delete A's output file when the whole works
was done. Yes, the user could do it manually, but compare:

  cmd aaa | wc

and

  cmd aaa bbb
  wc bbb
  rm bbb

If bbb is huge, one might run out of room, but with today's 'light my cigar
with disk blocks' life, not a problem - but it would involve more disk
traffic, as bbb would have to be written out in its entirety, not just have a
mall piece kept in the disk cache as with a pipe.

	Noel

^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-09-30 11:41 Douglas McIlroy
  0 siblings, 0 replies; 100+ messages in thread
From: Douglas McIlroy @ 2021-09-30 11:41 UTC (permalink / raw)
  To: TUHS main list

> one other thing that SLS breaks, for data files, is the whole Unix 'pipe'
> abstraction, which is at the heart of the whole Unix tools paradigm.

Multics had an IO system with an inherent notion of redirectable data
streams. Pipes could have--and eventually did (circa 1987)--fit into
that framework. I presume a pipe DIM (device interface manager)
was not hard to build once it was proposed and accepted.

Doug

^ permalink raw reply	[flat|nested] 100+ messages in thread
* Re: [TUHS] Systematic approach to command-line interfaces
@ 2021-10-01 12:11 Paul Ruizendaal
  0 siblings, 0 replies; 100+ messages in thread
From: Paul Ruizendaal @ 2021-10-01 12:11 UTC (permalink / raw)
  To: TUHS main list

Greg wrote:

> I guess pipe(2) kind of started this mess, [...]  Maybe I'm
> going to far with thinking pipe() could/should have just been a library
> call that used open(2) internally, perhaps connecting the descriptors by
> opening some kind of "cloning" device in the filesystem.

At times I’ve been pondering this as well. All of creat/open/pipe could have been rolled into just open(). It is not clear to me why this synthesis did not happen around the time of 7th edition; although it seems the creat/open merger happened in BSD around that time.

As to pipe(), the very first implementation returned just a single fd where writes echoed to reads. It was backed by a single disk buffer, so could only hold ~500 bytes, which was probably not enough in practice. Then it was reimplemented using an anonymous file as backing store and got the modern two fd system call. The latter probably arose as a convenient hack to store the two file pointers needed.

It would have been possible to implement the anonymous file solution still using a single fd, and storing the second file pointer in the inode. Maybe this felt as a worse hack at the time (the conceptual split in vnode / inode was still a decade into the future.)

With a single fd, it would also have been possible to have a cloning device for pipe’s as you suggest (e.g. /dev/pipe, somewhat analogous to the implementation of /dev/stdin in 10th edition). Arguably, in total code/data size this would not have been much different from pipe().

My guess is that from a 1975 perspective, creat/open/pipe was not perceived as something that needed fixing.


^ permalink raw reply	[flat|nested] 100+ messages in thread

end of thread, other threads:[~2021-10-01 12:12 UTC | newest]

Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-31 12:25 [TUHS] Systematic approach to command-line interfaces Michael Siegel
2021-07-31 13:05 ` Dan Halbert
2021-07-31 14:21 ` Adam Thornton
2021-07-31 14:25   ` Adam Thornton
2021-07-31 15:45 ` Richard Salz
2021-07-31 16:03   ` Clem Cole
2021-07-31 16:06     ` Richard Salz
2021-07-31 16:21       ` Clem Cole
2021-07-31 16:17     ` Clem Cole
2021-07-31 16:30       ` Dan Cross
2021-07-31 15:56 ` Paul Winalski
2021-07-31 16:19   ` Dan Cross
2021-08-01 17:44     ` Chet Ramey
2021-08-01 21:53       ` Dan Cross
2021-08-01 23:21         ` Chet Ramey
2021-08-01 23:36         ` John Cowan
2021-08-01 23:49           ` Larry McVoy
2021-08-02  0:28             ` Larry McVoy
2021-08-01 23:58           ` Dan Cross
2021-08-02  0:29             ` Steve Nickolas
2021-08-02  0:13           ` Andrew Warkentin
2021-08-02  0:18             ` John Cowan
2021-08-02  0:54               ` Andrew Warkentin
2021-08-02  1:04               ` Dan Cross
2021-08-02  1:05             ` Theodore Ts'o
2021-08-02  2:10               ` Andrew Warkentin
2021-08-02  2:32               ` Bakul Shah
2021-08-02 17:33             ` Lars Brinkhoff
2021-09-28 17:46             ` Greg A. Woods
2021-09-28 18:10               ` Larry McVoy
2021-09-29 16:40                 ` Greg A. Woods
2021-09-29 16:57                   ` Larry McVoy
2021-09-30 17:31                     ` Greg A. Woods
2021-09-29 23:10               ` Phil Budne
2021-08-02 17:37           ` Lars Brinkhoff
2021-08-02 18:52             ` Clem Cole
2021-08-02 20:59               ` John Cowan
2021-08-02 21:06                 ` Al Kossow
2021-08-02 21:14                 ` Clem Cole
2021-08-02 21:13               ` Clem Cole
2021-08-01 16:51   ` Michael Siegel
2021-08-01 17:31     ` Jon Steinhart
2021-07-31 16:41 ` Clem Cole
2021-07-31 17:41   ` John Cowan
2021-07-31 17:30 ` Anthony Martin
2021-07-31 17:46   ` John Cowan
2021-07-31 18:56   ` Michael Siegel
2021-07-31 19:41     ` Clem Cole
2021-07-31 21:30       ` Michael Siegel
2021-08-01 17:48     ` Chet Ramey
2021-08-01 19:23       ` Richard Salz
2021-08-01 23:26         ` Chet Ramey
2021-07-31 19:20 ` [TUHS] Systematic approach to command-line interfaces [ meta issues ] Jon Steinhart
2021-07-31 21:06   ` Richard Salz
2021-07-31 21:32     ` Jon Steinhart
2021-07-31 21:37       ` Richard Salz
2021-07-31 21:55         ` Jon Steinhart
2021-07-31 22:10       ` Warner Losh
2021-07-31 22:19         ` Larry McVoy
2021-07-31 22:20         ` Jon Steinhart
2021-07-31 23:26           ` Warner Losh
2021-07-31 23:41             ` Jon Steinhart
2021-07-31 22:04   ` Bakul Shah
2021-07-31 22:13     ` Larry McVoy
2021-07-31 22:14       ` Bakul Shah
2021-07-31 22:17         ` Bakul Shah
2021-07-31 22:16     ` Jon Steinhart
2021-07-31 22:20       ` Bakul Shah
2021-07-31 16:27 [TUHS] Systematic approach to command-line interfaces Nelson H. F. Beebe
2021-07-31 16:47 Ron Young
2021-08-02  2:34 ` Jim Carpenter
2021-08-02  2:38   ` Ron Young
2021-08-02  2:42 Douglas McIlroy
2021-08-02 14:58 ` Theodore Ts'o
2021-08-02 18:15   ` Adam Thornton
2021-08-02 18:24     ` Warner Losh
2021-08-02 20:55     ` John Cowan
2021-08-02 21:06       ` Jon Steinhart
2021-08-02 21:25         ` Dan Cross
2021-08-02 21:59           ` Jon Steinhart
2021-08-02 22:33             ` John Cowan
2021-08-03  0:21     ` Bakul Shah
2021-08-03  1:49       ` Jon Steinhart
2021-08-03  3:21         ` Adam Thornton
2021-08-03  3:27         ` Bakul Shah
2021-08-03  3:51           ` Jon Steinhart
2021-08-03  7:19   ` arnold
2021-08-03 23:12     ` Andrew Warkentin
2021-08-04 15:04       ` Paul Winalski
2021-08-03 15:01 Douglas McIlroy
2021-08-03 17:13 ` Tom Lyon via TUHS
2021-08-11 18:11   ` Tom Ivar Helbekkmo via TUHS
2021-08-11 21:24     ` Tom Lyon via TUHS
2021-08-03 19:12 Douglas McIlroy
2021-09-28 18:15 Noel Chiappa
2021-09-29 18:07 Noel Chiappa
2021-09-29 19:04 ` Dan Cross
2021-09-29 19:12 ` Larry McVoy
2021-09-30 11:41 Douglas McIlroy
2021-10-01 12:11 Paul Ruizendaal

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).