[Gnu-arch-users] Re: Extension language

[zander]

On Sat, Oct 18, 2003 at 04:20:44AM -0400, Miles Bader wrote:
> On Sat, Oct 18, 2003 at 09:48:48AM +0200, address@hidden wrote:
> > > Sure it (subprocess control w/o an intervening shell) works from Perl or
> > > Python, and I'm pretty sure Java. Likewise on win32.
> > 
> > The above (scsh) does not provide it; system calls /bin/sh, so how is this
> > done?
> 
> Did you actually look at the referenced web page?
Yes.
> 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.
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.

> > Making a technical decision based on "I'm pretty sure Java can.."  is
> > rather weak since I just told you it can't.
> 
> I've no idea about java, but perl certainly provides this sort of
> functionality.

What do you mean with 'this sort of functionality' ?
A call to system(), another call?   Just calling the scsh executable via
system?
What?
Its impossible to argue with people that don't say anything specific; which
command is it?  Do a man perlfunc and find out.

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

> > Btw; if you do know of a way to sidestep a shell; then you also can't put
> > env variables in your shell-environment anymore.  Making your first argument
> > moot.
>
> 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.
If you say its certainly possible; it would be nice to actually say what that 
way
is.  Argument your case, don't just point in the air.

> > I'm afraid that those solutions (which I would call workarounds) are not
> > adequate, if only because they are not well known or are worse then the 
> > thing
> > they try to prevent.
> 
> It's not at all clear what you mean by this.

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.
The part you cut away said that all those points have readily available 
solutions
which are things like scsh, creating a new translation package and other things.
Those solutions are workarounds since they don't really take away the problem
but provides a convenient way to handle them. Ignoring the fact that in a next
version things are going to break all again.
Thats what I mean with that statement.

-- 
Thomas Zander

pgp3h8OcB6AcF.pgp
Description: PGP signature