gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Extension language


From: Miles Bader
Subject: Re: [Gnu-arch-users] Re: Extension language
Date: Sat, 18 Oct 2003 09:20:45 -0400
User-agent: Mutt/1.3.28i

On Sat, Oct 18, 2003 at 11:18:45AM +0200, address@hidden wrote:
> > It describes process-manipulation stuff that's apparently based directly
> > on the exec/fork/pipe system calls (though with nice abstractions on top
> > too).
> 
> True; what's your point?
> Its not a drop in replacement of the system call.

Who _cares_?

Let's start again:

The question at hand is `Is a process-invocation model acceptable to call
tla?'  One of your objections to this model is that you said that invoking a
process involves the vagaries of shell quoting.

For most languages, however, this is _not an issue_, because _most_ languages
implement more direct process interfaces than `system', which do not use the
shell at all.  The fine details of such interfaces vary depending on the
language, but they're generally just a thin layer on top of
fork/exec/pipe/etc, and generally allow at least (1) direct invocation of the
process without using a shell, (2) obviously no quoting at all, (3) each
argument from a separate string, (4) environment variables to be specified.

Some languages that have such an interface: perl, java*, python.  In all of
these languages, there is no separate fork; to the user, it looks just like a
version of `system' that doesn't use the shell, and takes a list of arguments
instead of a single string -- which is usually just what you need!

[* I looked it up]

> Its just a library that needs bindings to each language (apart from C) to be
> able to talk to it.
> 
> In other words; the script writer still has to be aware of the problems and
> solutions; and has to learn many new ways to access data through a couple
> of layers of software.  Which really makes it just so hard he will just use
> something like perls "`" commands.

Um, hardly; they're widely used interfaces, and the only real difference
from using `system' is that you have to give a list of arguments instead of
a single string; in most cases, this is actually _more_ convenient, because
you've usually got various parameters in separate strings already.

> Its impossible to argue with people that don't say anything specific; which
> command is it?  Do a man perlfunc and find out.

Ok, I looked it up: simply call `system' with a list of strings instead of a
single string, and it will avoid the shell, and fork/exec the process
directly.

> >  As it's simple to do, I'm not sure why java _wouldn't_
> > provide such a facility.
> Still a _very_ weak basis to refute my claim.

   Runtime.exec(string_array)

[separate variants exist for specifying env vars etc]

> > Huh?  It's certainly not necessary to use a shell to pass environment
> > variables.
> 
> Please explain how you would pass something like 'export DEBUG=false' to
> the environment of the application you start using system. I'm assuming
> system here since I have not heard any alternative.

Most of the languages above have interfaces for specifying env vars when
invoking a process (e.g., in java it's Runtime.exec(args, env) ).

> The points that its hard to parse output text; that output format can
> change and all those points I pointed out before in this thread can not
> simply be solved; I certainly have not seen any example of how it can be
> solved on this list.

Look, I agree with you -- in many cases subprocesses can be a pain, because
of output parsing, etc.  I'd _love_ to have direct language-level interface
to lua (:-) or something.  This would make certain things easier.

But I've _written_ code that uses tla in a `programmatic' matter (in fact I
did it in awk, a language which only has `system' -- and I just wrote a
simple library function that does all the necessary magic to avoid problems
with quoting).  I can at least say that hey, it's really not that bad.  Tla's
command set and output formats are really pretty friendly from the point of
view of a typical scripting language.

I do think the question of whether a process-invocation model is annoying
enough to justify the effort to create a more direct interface is worth
discussing; the main purpose of this message is simply address the question
of whether `system' is really a problem or not.

-miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]