>> However if I try my own code ( bwtest::spawn simply spawns the command
>> ,puts the output to a file and returns the pid)
How exactly do you "spawn,", i.e. what Perl mechanism are you calling from
bwtest?
** Apologies again or my lack of perlness
**
** It's basically a C wrapper around Lib$spawn and now that I've checked
the vms.c codebase, it fairly obvious that
** it's not going to work with the waitpid as I havn't setup the correct
info or even pInfo
**
** Before I go off and try and make my spawn wrapper compatible with the
existing waitpid.
** Let me ask the basic question ,
** I need to execute some commands ( mostly Java) capture the
sys$output ( and possible sys$error), make sure the
** comand ran ( process is running) and then either wait for completion
or go off and do other things ( like launch other processes )
** and finaly come back and kill the "process" ( or wait for completion and
capture the exit status) after a period.
**
** Now
** 1. System
** 2. open(FOO, "java ...|") requires while(FOO) to catch output
** 3. `java this`
** will all create seperate processes , but all seem to operate in a
largely spawn/wait mode
** so is there an equivalent of spawn/nowait ?
Regards
Tony O'Callaghan
Software Consultant
Storm Technology Ltd.
Phone: 091-509773
Fax: 091-509770
Mobile: 087-2227490
Email: [EMAIL PROTECTED]
http://www.storm.ie
"Craig A.
Berry" To: [EMAIL PROTECTED]
<craigberry@m cc: [EMAIL PROTECTED]
ac.com> Subject: RE: what the heck is $^S (was
Re: waitpid return status)
05/06/2001
21:05
At 08:40 AM 6/5/2001 -0400, lane @ DUPHY4.Physics.Drexel.Edu wrote:
>[EMAIL PROTECTED] writes:
>> However if I try my own code ( bwtest::spawn simply spawns the command
>> ,puts the output to a file and returns the pid)
How exactly do you "spawn,", i.e. what Perl mechanism are you calling from
bwtest?
>> the first java class returns zero (0) as the VMS exit status and the 2nd
>> One (1)
>>
>> use vmsish qw(status);
>> use bwtest;
>> $pid= bwtest::spawn("java \"demos.dynany.Server\"","t.log");
>> waitpid($pid,0);
>> print "** $?**\n";
>
>It matters how you create the subprocess, and this is arguably exercising
>buggy/inconsistent code.
>
>The main (only?) ways to run a subprocess from Perl are:
>
>1 system('stuff'); # system() call
>2 `stuff`; # backticks
>3 open(FOO,'|stuff'); # piped i/o
>
>for 2 and 3, the piped i/o routines are used; they have the proper
>handling of return status and waitpid (and 'close()') sets $? correctly.
>
>But when I wrote the piping code, I didn't touch system() at all. That
>seemed like a good idea at the time, but now it's clear that system()
>needs to change to play well with waitpid and $?.
I think system() implies spawn/wait behavior, so is waitpid really
relevant?
And it already works with $? :
$ perl -e "use vmsish status; system('foobar'); print qq/** $? **/;"
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\FOOBAR\
** 229520 **
>Longer term, I'm going to have to do some more hacking on the code.
>What I have in mind is changing safe_popen to call a more general
>routine, something like:
>
> spawn_sub(command, input_filehandle, output_filehandle,
err_filehandle)
>
>that can deal with all combinations of filehandles being active or null.
>
> spawn_sub(command, null, null, null) -> system('command')
> spawn_sub(command, in, null, null) -> open(in,'|command')
> spawn_sub(command, null, out, null) -> open(out,'command|')
> spawn_sub(command, in, out, err) -> open3
>
>The code for piped i/o will stay pretty much the same in how it works,
>but system() would change, and there would be the possibility of
>implementing open3...
>
>It'll probably take me a few weeks to get working patches out. Now
>would be a good time to make suggestions for changes.
Excellent news. My only suggestion is to hack the mbx device driver and
make the damn things stream-oriented while you're at it ;-).
