Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 21 Nov 2012 09:53:02 +0100
From:      Polytropon <freebsd@edvax.de>
To:        jb <jb.1234abcd@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: portsnap
Message-ID:  <20121121095302.82a3708e.freebsd@edvax.de>
In-Reply-To: <loom.20121120T193059-797@post.gmane.org>
References:  <loom.20121120T173108-456@post.gmane.org> <201211201826.qAKIQq8C097714@mail.r-bonomi.com> <loom.20121120T193059-797@post.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help 
On Tue, 20 Nov 2012 18:42:37 +0000 (UTC), jb wrote:
> Robert Bonomi <bonomi <at> mail.r-bonomi.com> writes:
> 
> > ... 
> > > > 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.
> 
> 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).

NB: "Modifier" term borrowed from VMS here. :-)

Examples:

	$ ls -la
	Here the "ls" program will change its default behaviour
	and list all stuff in long format.

	$ portsnap fetch extract
	Here the "portsnap" program will first fetch new ports
	(1st command) and then extract it (2nd command).

However, I agree that this is primarily about _interpretation_
of the word "command", and especially when the consideration
"command line option can be command to program" is taken. This
especially applies when a program can perform actions which are
fundamentally different (fetch != extract) in opposite to "just"
modifying "the same" operation (list files: how?).

Note that command line arguments can also contain associations.
A famous example is dd. In other programs, like cp or mv, the
position of the command line argument decides about its inter-
pretation (which is source, which is destination).



> > > 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.
> 
> > You lie.  A "command" does not have to have the attributes of a command-line
> > invocation.
> 
> Well, a second nature ... But, it is an honor :-)

At least those are entertaining lies. :-)



> To drive the point:
> let's assume that it is a valid syntax to pass a parameter like this:
> "ls -al"
> or much better, command="<command>", like this:
> command="ls -al"
> then it would be clear that a command (parameter) is passed to CLI command.
> This kind of command parameter passing fulfilles the definition of a command
> as referenced.

This is a fully valid interpretation, especially from the shell's
point of view.

But also consider programs that drive their own CLI. One of them
is "mail". It presents a prompt and expects you to enter a command.
It will not system() that command, but act according to it.



> If you are familiar with C function system(), you will have easier time to
> understand:
> http://www.cplusplus.com/reference/clibrary/cstdlib/system/
> The prototype is:
> int system ( const char * command );

According to "man 3 system", it is

	int system(const char *string);

with the following description: "The system() function hands the
argument string to the command interpreter sh(1).  The calling
process waits for the shell to finish executing the command,
ignoring SIGINT and SIGQUIT, and blocking SIGCHLD. If string is
a NULL pointer, system() will return non-zero if the command
interpreter sh(1) is available, and zero if it is not."

Again, we get new terminology: "argument". The string in question
is actually considered a command in the first meaning mentioned.
And again, there's nothing wrong in interpreting _parts_ of that
string to be commands to the program actually called.



> The command "ls -al" (yes, it is a command as referenced) is a parameter to
> system() function:
> system("ls -al");

Ah, a parameter! Not a functional argument? :-)

I'm not even sure where to draw the line. A definition I've heared
at university is this: The "const char *string" is the parameter,
and "ls -la" is the argument... or was it vice versa? One describes
the abstract form (in the function prototype), and the other one
describes the actual content...



> It just says, execute that command "ls -al" in the existing execution
> environment.

Nothing wrong here.



> The reason I go so by the book about it is that "words have meaning" and
> definitions :-)

Depending on _what_ book you read, things may change. :-)

For example, consider an IBM mainframe manual for standard programs.
They acquire a "control file", typically inside the job stream, and
it contains _what_? Commands! It's not that those commands cause
any program to launch; instead, they instruct a versatile program
in what to do (e. g. IEHDASDR if it should DUMP or RESTORE, because
it can do both and more; still only _one_ program is called).





-- 
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?20121121095302.82a3708e.freebsd>