From owner-freebsd-questions@FreeBSD.ORG Tue Nov 20 18:25:53 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F249F324 for ; Tue, 20 Nov 2012 18:25:53 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7468FC17 for ; Tue, 20 Nov 2012 18:25:53 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id qAKIQq8C097714 for freebsd-questions@freebsd.org; Tue, 20 Nov 2012 12:26:52 -0600 (CST) Date: Tue, 20 Nov 2012 12:26:52 -0600 (CST) From: Robert Bonomi Message-Id: <201211201826.qAKIQq8C097714@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: portsnap In-Reply-To: X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:25:54 -0000 > From owner-freebsd-questions@freebsd.org Tue Nov 20 11:14:25 2012 > To: freebsd-questions@freebsd.org > From: jb > Subject: Re: portsnap > Date: Tue, 20 Nov 2012 17:12:46 +0000 (UTC) > > Robert Bonomi 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 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.