[Top][All Lists]

[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

> >  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.


[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.

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]