EXIT
Fairlight
fairlite at fairlite.com
Mon Mar 9 11:14:29 PDT 2015
You say that like it has some meaning, Ken. Given the utterly shallow
documentation filePro has (-rw .. -rz are still documented as deeply as
mirror plating, and about as transparently - as witnessed by an exchange
I had with a client this week), saying *COMMAND* and *FUNCTION* in the
context of filePro's API to any underlying system functionality is
laughable.
What are you meaning, -exactly-, by "*COMMAND*"? Because I've -always-
considered the damned thing a function which is a wrapper around system(2).
If it points to an underlying system function, I consider it a function
itself. Full stop.
You apparently have some seemingly arbitrary (but differing) definitions
of the two which are not clearly presented, and which appear to follow
arbitrary rules which you have yet to properly and concisely explain.
Apparently it's not represented by the syntax, as I'd queried...
So enlighten me/us...
mark->
On Mon, Mar 09, 2015 at 01:08:09PM -0400, Kenneth Brody thus spoke:
> On 3/9/2015 11:49 AM, Fairlight wrote:
> >What's there difference between invoking the two? Using a variable for the
> >return value, or using parentheses? Or both?
>
> The difference is that one is a *COMMAND*:
>
> SYSTEM command_to_execute
>
> and the other is a *FUNCTION*:
>
> status = SYSTEM( command_to_execute )
>
> >
> >m->
> >
> >On Mon, Mar 09, 2015 at 09:06:05AM -0400, Kenneth Brody thus spoke:
> >>The SYSTEM *command* was never "redone". Rather, as I wrote in my
> >>original reply (quoted above), 5.6 introduced the SYSTEM()
> >>*function*.
> >
>
> --
> Kenneth Brody
>
--
Audio panton, cogito singularis.
More information about the Filepro-list
mailing list