portsnap

[Robert Bonomi]

> From owner-freebsd-questions at freebsd.org  Tue Nov 20 11:14:25 2012
> To: freebsd-questions at freebsd.org
> From: jb <jb.1234abcd at gmail.com>
> Subject: Re: portsnap
> Date: Tue, 20 Nov 2012 17:12:46 +0000 (UTC)
>
> Robert Bonomi <bonomi <at> mail.r-bonomi.com> writes:
>
> > ...
> > > http://en.wikipedia.org/wiki/Command-line_interface
> > > ...
> > > The general pattern of an OS command line interface is: prompt 
> > > command param1 param2 param3 ... paramN
> >
> >  No argument -- for _that_ meaning of the word.  That, however, is not 
> >  the only valid usage or interpretation of it.
> >
> > The truth that you refuse to acknowledge is that in *many* cases, one 
> > or more of the 'params' on the command line are commands TO THE 
> > APPlICATION BEING INVOKED.

> > > A simple CLI will display a prompt, accept a "command line" typed by 
> > > the
> > >  [drivelectomy]
> > >  So, we are discussing here things that are obvious. People who write 
> > >  technical or user manuals should have a clue of what they are 
> > >  writing and talking about (e.g. what is "a command", also called "an 
> > >  entry"). Otherwise they screw up the users and "it's a software 
> > >  error" sysadmins.
> >
> > the authors of the portsnap docs (and the _numerous_ other applications 
> > that describe the use of certain keywords used as input to that 
> > appication ARE correct -- despite your boneheaded denial of that fact.
> >
> > A "command" specifies, to the application to which it is directed, 
> > _what_ (or _which_, if you prefer) operation/activity/function is to be 
> > performed. In grammar terms it is a =verb=.
> >
> > A 'parameter'/'option'/'switch'/etc. instructs the application to which 
> > it is directed to , _how_ to perform the particular action.  It 
> > _modifies_ the action to be performed.  In grammar terms it is an 
> > =adverb=.
> >
> > This distinction has been known to, understood, and employed by those 
> > who write/read/use technical instructions for well over THREE HUNDRED 
> > years. (early multi-function machinery, such as a crane, could only 
> > perform one action at a time -- e.g. traverse, adjust boom, lift; you 
> > moved one set of controls to command the machine _which_ action to 
> > perform, and then another set of controls to ccntrol how it is done.
>
> ... also responding to kpneal <at> pobox.com> ...
>
> With regard to definition of "a command" as we practice and argue about 
> here:
>
> In general (see bash(1), SHELL GRAMMAR, Simple Commands), a command is an 
> executable preceded by optional vars and followed by optional parameters.

Repeating:

  No argument -- for _that_ meaning of the word.  That, however, is not 
  the only valid usage or interpretation of it.

  The truth that you refuse to acknowledge is that in *many* cases, one 
  or more of the 'params' on the command line are commands TO THE 
  APPlICATION BEING INVOKED.

> Look at PORTSNAP(8)'s synopsis again. The command is 'portsnap', anything 
> else are parameters to it.

According to the manpage some of those parameters ARE described as commands.

A form of usage/description employed by the first *professional* documentation
specialists at Bell Labs (also Dartmouth, Xerox, and others) more than 40
years ago (yes, 'before Unix') and still in use by documentation professionals
_today_.

> If you call a parameter a command here, you imply that it has attributes 
> of a command, which clearly does not, as referenced by me above.

You lie.  A "command" does not have to have the attributes of a command-line
invocation.

> So, basically, it is an indicator, verbosely (but not required to be so 
> if it were also verbosely defined in man page) describing an action 
> parameter, e.g. extract, telling the actual 'portsnap' command what to do 
> (yes - what to do, and not how to do it).

It has been tradition in the Unix community (and elsewhere) to refer to
what you call 'action parameters' as "commands" -- especially in formal
system documentation -- for well over THREE DECADES.

Your insistance that 'command' can ONLY refer to a command-line invocation
is contrary to 'plain English', 30+ years of Unix history/tradition, and
another 25+ years of computing history before that.