I'm adding an exec opcode alongside the spawn opcode. Does what you'd
expect an exec to do.
I've updated config/gen/platform generic/exec.c with proper code, and
win32/exec.c and ansi/exec.c with a stub that pitches a fit if you
try it, though I'd love it if someone with windows experience could
fill in the blank there.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Just add an _ before exec.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Cool. On the Unix platforms we exec off 'sh' and pass in parameters
(so we get command parameters split up right, IIRC). I'm presuming we
don't do the same for Windows, so I'll make it the plain command and
hope it all works out.
Thanks.
> Cool. On the Unix platforms we exec off 'sh' and pass in parameters
> (so we get command parameters split up right, IIRC). I'm presuming we
> don't do the same for Windows, so I'll make it the plain command and
> hope it all works out.
Well, that's one way you can do it, but it causes a ton of headaches,
e.g. because
exec "echo <user's text goes here>"
gets shell interpretation and fails, so by way of example only, Perl 5
allows for both usages depending on what you pass it. Parrot could
easily make the distinction based on being passed a string value or a
PMC array of some sort and end up with roughly the same functionality as
Perl (though Perl itself would not use this as-is, as it decides further
based on the content of the string, and will call raw exec(2) on the
results of splitting the string on whitespace if no shell metacharacters
occur, but I think that's a bit too much Perlishness to put in Parrot).
Either way, Parrot really HAS to provide a raw POSIX exec, as it cannot
be faked from a shell-using variant correctly.
> Parrot could
> easily make the distinction based on being passed a string value or a
> PMC array of some sort and end up with roughly the same functionality as
> Perl (though Perl itself would not use this as-is, as it decides further
> based on the content of the string, and will call raw exec(2) on the
> results of splitting the string on whitespace if no shell metacharacters
> occur, but I think that's a bit too much Perlishness to put in Parrot).
"Run-on sentence from hell" barely begins to describe the horror... I'm
so sorry about that. Please, do me a favor and breath whenever you feel
like it.... ;-)
Yeah, we really *should* do it right, rather than take the cheating
way out as we are now. I'll go add this to the TODO list.
Jonathan
Applied, thanks!