Date: Wed, 21 Nov 2012 10:43:30 +0000 (UTC) From: jb <jb.1234abcd@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: portsnap Message-ID: <loom.20121121T113544-519@post.gmane.org> References: <loom.20121120T173108-456@post.gmane.org> <201211201826.qAKIQq8C097714@mail.r-bonomi.com> <loom.20121120T193059-797@post.gmane.org> <20121121095302.82a3708e.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Polytropon <freebsd <at> edvax.de> writes:
> ...
> > Yes, it is a keyword, a keyword parameter that tells CLI command what to do
> > (yes, a keyword that may be taken verbatim or translated into an internal
> > command parameter(s), a keyword that represents an action).
> > But, it is not a command, or parameter of type command.
>
> I think Robert is right (which implies that you are wrong), at
> least in acknowledging the _possibility_ to interpret _certain_
> command line arguments as "commands to the program" (where a
> program can do various actions), in opposite to a "modifier"
> (which changes the way the "one action" a program performs
> in a certain way).
> ...
Putting aside the linguistics about executable command, entry, function,
parameter, and argument - let's reduce the case to one common ground, so we
can compare them.
The are two entities, each having in their description as receiving a command
as a parameter, namely:
- portsnap ... command ...
e.g. portsnap fetch
- system(command);
e.g. system("ls -al");
The former is passed an action keyword as an argument (I like the word
"keyword"; we could use "command keyword" as perhaps even a better fit and
the closest to describe the nature of it).
The latter is passed a command as an argument.
So, the manual for portsnap(8) is imprecise, actually unfortunate because
misleading.
jb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20121121T113544-519>