[TUHS] 'Command subcommand ...' history

[TUHS] 'Command subcommand ...' history

[Tim Bradshaw]

Lots of tools now seem to use this strategy: there's some kind of wrapper which has its own set of commands (which in turn might have further subcommands).  So for instance

    git remote add ...

is a two layer thing.

Without getting into an argument about whether that's a reasonable or ideologically-correct approach, I was wondering what the early examples of this kind of wrapper-command approach were.  I think the first time I noticed it was CVS, which made you say `cvs co ...` where RCS & SCCS had a bunch of individual commands (actually: did SCCS?).  But I think it's possible to argue that ifconfig was an earlier example of the same thing.  I was thinking about dd as well, but I don't think that's the same: they're really options not commands I think.

Relatedly, does this style originate on some other OS?

--tim

(I realise that in the case of many of these things, particularly git, the wrapper is just dispatching to other tools that do the werk: it's the command style I'm interested in not how it's implemented.)

[TUHS] 'Command subcommand ...' history

[Larry McVoy]

On Fri, Mar 24, 2017 at 03:42:02PM +0000, Tim Bradshaw wrote:
> Lots of tools now seem to use this strategy: there's some kind of wrapper which has its own set of commands (which in turn might have further subcommands).  So for instance
> 
>     git remote add ...
> 
> is a two layer thing.
> 
> Without getting into an argument about whether that's a reasonable or ideologically-correct approach, I was wondering what the early examples of this kind of wrapper-command approach were.  I think the first time I noticed it was CVS, which made you say `cvs co ...` where RCS & SCCS had a bunch of individual commands (actually: did SCCS?).  But I think it's possible to argue that ifconfig was an earlier example of the same thing.  I was thinking about dd as well, but I don't think that's the same: they're really options not commands I think.

BSD's sccs wrapper worked this way, I believe thats where I saw it first.

[TUHS] 'Command subcommand ...' history

[Clem Cole]

SCCS started out as single commands, and many of us learned to use that way
(I still do - for simple things I still find it easy to use - including as
the front end to all my troff).   Anyway, a couple of the SCCS macro
commands tended to be used together or in sequence and that is the key
step.   When Eric started to use SCCS for development of Ingres in the late
1970s, as Larry pointed out, Eric wrote the BSD sccs command wrapper.***

That said, I'm not sure Eric's sccs command was the first time I had seen
tool wrapper, although it may have been the first "tool" wrapper as a C
program in that sense.  I have some memories of a couple of others that
were shell scripts, but I can't remember any specifics, other than the C
compiler itself (cc was originally a shell script) and the original man
command.   I do remember looking at what Eric did when I first came across
it, as I recall I had to mess with it -- may it did not run on the 40 class
systems without some hacking - I really don't remember why.

I think the key is that shell scripts were becoming more and more things we
wrote with every day and more and more tools became scripts.   But on the
PDP-11, the shell was limited and took resources, so converting from a
shell script to C program was not unusual for speed.   The next step was
things like Eric's sccs command.

Clem


*** As an aside, it is an interesting question is how the SCCS commands and
CPIO sources originally made it to UCB.  Those tools were part of PWB 1.0
and 2.0 - which was not released to Universities - although Mashey had
published at least one paper about it and was an ACM National Lecturer at
the time.  Hence, many people knew about SCCS (I had heard him talk about
it 1979 at conference in Oregon).   Anyway, other than those tools, I do
not see much other evidence of PWB's specifics in the UCB archives.   I've
always guessed it was an unnamed "OYOC" student that left them there or it
may also have come from the Joy/Kowaski - uMich connection.  I don't think
it was Ken because Ken wrote tar so he is unlikely to have left cpio.   But
Ted was always fan of cpio (and may have had a hand in its creation).
 We'll probably never know ;-)  I certainly had become familiar with the
PWB tools a few years earlier at CMU, via the same type of path "OYOC"
 (either Phil or Ted) - which is also why so many of us knew about lots of
the work at AT&T - it was pretty well written about and published.

On Fri, Mar 24, 2017 at 11:44 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Fri, Mar 24, 2017 at 03:42:02PM +0000, Tim Bradshaw wrote:
> > Lots of tools now seem to use this strategy: there's some kind of
> wrapper which has its own set of commands (which in turn might have further
> subcommands).  So for instance
> >
> >     git remote add ...
> >
> > is a two layer thing.
> >
> > Without getting into an argument about whether that's a reasonable or
> ideologically-correct approach, I was wondering what the early examples of
> this kind of wrapper-command approach were.  I think the first time I
> noticed it was CVS, which made you say `cvs co ...` where RCS & SCCS had a
> bunch of individual commands (actually: did SCCS?).  But I think it's
> possible to argue that ifconfig was an earlier example of the same thing.
> I was thinking about dd as well, but I don't think that's the same: they're
> really options not commands I think.
>
> BSD's sccs wrapper worked this way, I believe thats where I saw it first.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170327/b1453d15/attachment.html>

[TUHS] 'Command subcommand ...' history

[Arthur Krewat]

The current SCCS certainly takes subcommands, but I have no idea if it 
started out that way.

ifconfig is more a set of flags than subcommands.

And don't get me started about dd - who wrote that anyway? Must have 
been an IBM guy :)

dd breaks all the norms for using shell wildcard expansions. You can't 
do: dd if=*.tar of=/dev/rmt/0cbn bs=128k

Assuming, of course, you only had one tar file you wanted to write to tape.



On 3/24/2017 11:42 AM, Tim Bradshaw wrote:
> Lots of tools now seem to use this strategy: there's some kind of wrapper which has its own set of commands (which in turn might have further subcommands).  So for instance
>
>      git remote add ...
>
> is a two layer thing.
>
> Without getting into an argument about whether that's a reasonable or ideologically-correct approach, I was wondering what the early examples of this kind of wrapper-command approach were.  I think the first time I noticed it was CVS, which made you say `cvs co ...` where RCS & SCCS had a bunch of individual commands (actually: did SCCS?).  But I think it's possible to argue that ifconfig was an earlier example of the same thing.  I was thinking about dd as well, but I don't think that's the same: they're really options not commands I think.
>
> Relatedly, does this style originate on some other OS?
>
> --tim
>
> (I realise that in the case of many of these things, particularly git, the wrapper is just dispatching to other tools that do the werk: it's the command style I'm interested in not how it's implemented.)
>

[TUHS] 'Command subcommand ...' history

[Paul Winalski]

On 3/24/17, Tim Bradshaw <tfb at tfeb.org> wrote:
> Lots of tools now seem to use this strategy: there's some kind of wrapper
> which has its own set of commands (which in turn might have further
> subcommands).  So for instance
>
>     git remote add ...

[snip]
>
> Relatedly, does this style originate on some other OS?
>
> --tim

This command style was the standard and encouraged approach on many of
DEC's operating systems.  Digital Command Language (DCL), the command
language for TOPS-20 and VMS, implemented most of the common system
commands this way:  A lot of packages or subsystems, such as mail,
source code control (Code Management System--CMS), and whatnot were
implemented using this design.  The command verb was usually the
package name, and the subcommands implemented functions in that
package.  Very often you could just give the command name and that
entered the package in interactive mode--it would prompt for
subcommands until you exited the subsystem.

I'm pretty sure this command design style was used in VM/CMS and CDC PLATO, too.

-Paul W.

[TUHS] 'Command subcommand ...' history

[Doug McIlroy]

In some sense the "command subcommand" syntax dates from ar in v1,
though option flags were catenated with the mandatory subcommand.
The revolutionary notion that flags/subcommands might be denoted
by more than one letter originated at PWB (in "find", IIRC).

Doug