[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
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?
- Re: [Gnu-arch-users] Extension language, (continued)
- Re: [Gnu-arch-users] Extension language, Tom Lord, 2003/10/17
- Re: [Gnu-arch-users] Extension language, Joshua Haberman, 2003/10/17
- Re: [Gnu-arch-users] Extension language, Tom Lord, 2003/10/17
- [Gnu-arch-users] Re: Extension language, zander, 2003/10/17
- Re: [Gnu-arch-users] Re: Extension language, Charles Duffy, 2003/10/17
- Re: [Gnu-arch-users] Re: Extension language, zander, 2003/10/18
- Re: [Gnu-arch-users] Re: Extension language, Miles Bader, 2003/10/18
- [Gnu-arch-users] Re: Extension language, zander, 2003/10/18
- Re: [Gnu-arch-users] Re: Extension language, Charles Duffy, 2003/10/18
- [Gnu-arch-users] Topicality, Charles Duffy, 2003/10/18
- Re: [Gnu-arch-users] Re: Extension language,
Miles Bader <=
- Re: [Gnu-arch-users] Re: Extension language, Dustin Sallings, 2003/10/18
- Re: [Gnu-arch-users] Re: Extension language, Charles Duffy, 2003/10/18
- Re: [Gnu-arch-users] Extension language, Joshua Haberman, 2003/10/18
- Native windows support (was Re: [Gnu-arch-users] Extension language), Tom Lord, 2003/10/18
- Re: Native windows support (was Re: [Gnu-arch-users] Extension language), Joshua Haberman, 2003/10/18
- Re: Native windows support (was Re: [Gnu-arch-users] Extension language), Colin Walters, 2003/10/18
- [Gnu-arch-users] Re: Native windows support, zander, 2003/10/19
- Re: Native windows support (was Re: [Gnu-arch-users] Extension language), Karel Gardas, 2003/10/20
- Re: [Gnu-arch-users] Extension language, Stephen J. Turnbull, 2003/10/21
- Re: [Gnu-arch-users] Extension language, Tom Lord, 2003/10/16