Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Nov 2012 10:40:59 +0100
From:      Polytropon <freebsd@edvax.de>
To:        jb <jb.1234abcd@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: portsnap
Message-ID:  <20121122104059.33dd4637.freebsd@edvax.de>
In-Reply-To: <loom.20121121T224253-272@post.gmane.org>
References:  <loom.20121121T113544-519@post.gmane.org> <201211211959.qALJxa2u013758@mail.r-bonomi.com> <loom.20121121T224253-272@post.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121122104059.33dd4637.freebsd>