From owner-freebsd-questions@FreeBSD.ORG Thu Nov 22 09:41:06 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 D1250FF5 for ; Thu, 22 Nov 2012 09:41:06 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE6C8FC14 for ; Thu, 22 Nov 2012 09:41:05 +0000 (UTC) Received: from r56.edvax.de (port-92-195-51-39.dynamic.qsc.de [92.195.51.39]) by mx01.qsc.de (Postfix) with ESMTP id 565DF3CBF4; Thu, 22 Nov 2012 10:40:58 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id qAM9exv0001903; Thu, 22 Nov 2012 10:40:59 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Thu, 22 Nov 2012 10:40:59 +0100 From: Polytropon To: jb Subject: Re: portsnap Message-Id: <20121122104059.33dd4637.freebsd@edvax.de> In-Reply-To: References: <201211211959.qALJxa2u013758@mail.r-bonomi.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 09:41:06 -0000 On Wed, 21 Nov 2012 21:44:40 +0000 (UTC), jb wrote: > This is not the same what portsnap(8) does: > portsnap ... command ... > This "command" word is non-executable by itself; it has a meaning only as > a special word passed to portsnap command to tell it what to do internally, > just a kind of special indicator to be used for conditional processing: > if arg=fetch then do-fetch-routine > else if arg=update then do-update-routine > else .... That is _one_ possibility for interpretation. However, the bare word "command" carries two, maybe three aspects. 1st: the commander: _who_ provides the command? 2nd: the command content: _what_ is to be done? 3rd: the commanded one: _who_ will execute the command? For shell commands, it's obvious: The user commands the shell to execute the program provided as a command. For programs with multiple functionality, this interpretation also _perfectly_ works and is consistent with documentation, as Robert explained, of decates of UNIX, maybe pre-UNIX and also non-UNIX history. Of course the _internal_ interpretation of "commands given to a program" _by_ that program usually is not as simple as doing a system() library call. Something like a if-then-tree can be imagined, even when written in assembly. Still the "functional interpretation with 3 aspects" as mentioned above _will_ apply, even though the mechanisms are completely different from those of a CLI. So for the example of "portsnap fetch extract", it works to use the above concept: The user calls the "portsnap" program and commands it to do "fetch", then "extract"; the portsnap program will "internally" act according to those commands which are not an aspect of the CLI's responsibility anymore (no expansion or interpretation). Also note that this concept can even be applied to editors. >From "man vi": "The last line of the screen is used for you to give commands to vi, and for vi to give information to you." So those are also considered commands _within the context of vi_. Even the keys to move the cursor are considered a command by the manual writer. Context seems to matter a lot. > Well, being a liar is an honorable trait :-) Allow me to answer with a quote: Bashir: What I want to know is, out of all the stories you told me which ones were true and which ones weren't? Garak: My dear doctor... they're all true. Bashir: Even the lies? Garak: Especially the lies. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...