[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Potentially issues with "system" command (Nuby

Thomas Luedeke

8/13/2008 7:04:00 PM

This question is a little complicated, so I'll try to describe the
underlying issue in detail.

I'm using a Ruby script as a "glue" to link several engineering codes
together. To run each individual code, we utilize a production
submission system (call it 'PROD'). So I'm using Ruby to create input
files, submit the underlying engineering code run by invoking PROD with
the input file I've created. I then post-process the output of the
engineering code, and link it up to the next code by creating new input
files.

To invoke PROD, I'm using a system command of the type 'system( "PROD
options" )', where everything inside the single quotes is the command I
issue, and the options are PROD options.

This works pretty well until in one of the executions of an underlying
engineering code, the code prematurely terminates in the middle of a
run. If I take the identical input file and run it directly (using
*exactly* the same command as the system call above), it runs perfectly.

Are there some effects of "system" that I'm not aware of, being that I'm
a Nuby? One thought I had is that numerous system calls chew up memory
until I simply cannot run anything more.

Any speculations that anybody might have??

Respectfully, TPL
--
Posted via http://www.ruby-....

21 Answers

Thomas Luedeke

8/13/2008 7:13:00 PM

0

Thomas Luedeke wrote:
> This question is a little complicated, so I'll try to describe the
> underlying issue in detail.
>
> I'm using a Ruby script as a "glue" to link several engineering codes
> together. To run each individual code, we utilize a production
> submission system (call it 'PROD'). So I'm using Ruby to create input
> files, submit the underlying engineering code run by invoking PROD with
> the input file I've created. I then post-process the output of the
> engineering code, and link it up to the next code by creating new input
> files.
>
> To invoke PROD, I'm using a system command of the type 'system( "PROD
> options" )', where everything inside the single quotes is the command I
> issue, and the options are PROD options.
>
> This works pretty well until in one of the executions of an underlying
> engineering code, the code prematurely terminates in the middle of a
> run. If I take the identical input file and run it directly (using
> *exactly* the same command as the system call above), it runs perfectly.
>
> Are there some effects of "system" that I'm not aware of, being that I'm
> a Nuby? One thought I had is that numerous system calls chew up memory
> until I simply cannot run anything more.
>
> Any speculations that anybody might have??
>
> Respectfully, TPL


Just as clarification, I'm not doing anything process-wise (nothing like
fork). I just make the system call, wait until it is done, move to the
area where the output files are, then start the linkage with the next
code.
--
Posted via http://www.ruby-....

Thomas Luedeke

8/13/2008 8:14:00 PM

0

Thomas Luedeke wrote:
> Thomas Luedeke wrote:
>> This question is a little complicated, so I'll try to describe the
>> underlying issue in detail.
>>
>> I'm using a Ruby script as a "glue" to link several engineering codes
>> together. To run each individual code, we utilize a production
>> submission system (call it 'PROD'). So I'm using Ruby to create input
>> files, submit the underlying engineering code run by invoking PROD with
>> the input file I've created. I then post-process the output of the
>> engineering code, and link it up to the next code by creating new input
>> files.
>>
>> To invoke PROD, I'm using a system command of the type 'system( "PROD
>> options" )', where everything inside the single quotes is the command I
>> issue, and the options are PROD options.
>>
>> This works pretty well until in one of the executions of an underlying
>> engineering code, the code prematurely terminates in the middle of a
>> run. If I take the identical input file and run it directly (using
>> *exactly* the same command as the system call above), it runs perfectly.
>>
>> Are there some effects of "system" that I'm not aware of, being that I'm
>> a Nuby? One thought I had is that numerous system calls chew up memory
>> until I simply cannot run anything more.
>>
>> Any speculations that anybody might have??
>>
>> Respectfully, TPL
>
>
> Just as clarification, I'm not doing anything process-wise (nothing like
> fork). I just make the system call, wait until it is done, move to the
> area where the output files are, then start the linkage with the next
> code.


Sorry, one last clarification. If I write a three line code running the
same input file, using the same system command, it runs to completion.
So something with regards to the lengthy script is interfering with the
process. Is this indicative of a memory issue?
--
Posted via http://www.ruby-....

Dave Thomas

8/13/2008 8:30:00 PM

0


On Aug 13, 2008, at 3:13 PM, Thomas Luedeke wrote:

> Sorry, one last clarification. If I write a three line code running
> the
> same input file, using the same system command, it runs to
> completion.
> So something with regards to the lengthy script is interfering with
> the
> process. Is this indicative of a memory issue?
> --


What's the termination status in $?. That may tell you why your
subprocess died.



Dave

Thomas Luedeke

8/13/2008 8:33:00 PM

0

Dave Thomas wrote:
> On Aug 13, 2008, at 3:13 PM, Thomas Luedeke wrote:
>
>> Sorry, one last clarification. If I write a three line code running
>> the
>> same input file, using the same system command, it runs to
>> completion.
>> So something with regards to the lengthy script is interfering with
>> the
>> process. Is this indicative of a memory issue?
>> --
>
>
> What's the termination status in $?. That may tell you why your
> subprocess died.
>
>
>
> Dave


I'm pretty new at this - what is the command to do so?
--
Posted via http://www.ruby-....

Robert Klemme

8/13/2008 8:50:00 PM

0

On 13.08.2008 22:32, Thomas Luedeke wrote:
> Dave Thomas wrote:
>> On Aug 13, 2008, at 3:13 PM, Thomas Luedeke wrote:
>>
>>> Sorry, one last clarification. If I write a three line code running
>>> the
>>> same input file, using the same system command, it runs to
>>> completion.
>>> So something with regards to the lengthy script is interfering with
>>> the
>>> process. Is this indicative of a memory issue?
>>> --
>>
>> What's the termination status in $?. That may tell you why your
>> subprocess died.

> I'm pretty new at this - what is the command to do so?

Place a "p $?" in the line after your system command.

On which platform and Ruby version are you? What shell are you using
when executing the command directly?

One effect of system you might not be aware of is that there will be a
shell invoked if you use a single string. I have no idea whether this
is related to your issue but it's certainly something to keep around in
the back of your mind.

Cheers

robert

Dave Thomas

8/13/2008 8:51:00 PM

0


On Aug 13, 2008, at 3:32 PM, Thomas Luedeke wrote:

> I'm pretty new at this - what is the command to do so?


dave[ATCOCOA/Book 15:47:45] ri Process::Status
------------------------------------------------- Class: Process::Status
Process::Status encapsulates the information on the status of a
running or terminated system process. The built-in variable $? is
either nil or a Process::Status object.

fork { exit 99 } #=> 26557
Process.wait #=> 26557
$?.class #=> Process::Status
$?.to_i #=> 25344
$? >> 8 #=> 99
$?.stopped? #=> false
$?.exited? #=> true
$?.exitstatus #=> 99

Posix systems record information on processes using a 16-bit
integer. The lower bits record the process status (stopped,
exited, signaled) and the upper bits possibly contain additional
information (for example the program's return code in the case of
exited processes). Pre Ruby 1.8, these bits were exposed directly
to the Ruby program. Ruby now encapsulates these in a
Process::Status object. To maximize compatibility, however, these
objects retain a bit-oriented interface. In the descriptions that
follow, when we talk about the integer value of stat, we're
referring to this 16 bit value.


You can just use

p $?

to get information. If it was signaled (perhaps because a process
limit was exceeded) you can find the cause.

Dave

Thomas Luedeke

8/13/2008 8:59:00 PM

0

Dave Thomas wrote:
> On Aug 13, 2008, at 3:32 PM, Thomas Luedeke wrote:
>
>> I'm pretty new at this - what is the command to do so?
>
>
> dave[ATCOCOA/Book 15:47:45] ri Process::Status
> ------------------------------------------------- Class: Process::Status
> Process::Status encapsulates the information on the status of a
> running or terminated system process. The built-in variable $? is
> either nil or a Process::Status object.
>
> fork { exit 99 } #=> 26557
> Process.wait #=> 26557
> $?.class #=> Process::Status
> $?.to_i #=> 25344
> $? >> 8 #=> 99
> $?.stopped? #=> false
> $?.exited? #=> true
> $?.exitstatus #=> 99
>
> Posix systems record information on processes using a 16-bit
> integer. The lower bits record the process status (stopped,
> exited, signaled) and the upper bits possibly contain additional
> information (for example the program's return code in the case of
> exited processes). Pre Ruby 1.8, these bits were exposed directly
> to the Ruby program. Ruby now encapsulates these in a
> Process::Status object. To maximize compatibility, however, these
> objects retain a bit-oriented interface. In the descriptions that
> follow, when we talk about the integer value of stat, we're
> referring to this 16 bit value.
>
>
> You can just use
>
> p $?
>
> to get information. If it was signaled (perhaps because a process
> limit was exceeded) you can find the cause.
>
> Dave



Hmmm. This doesn't seem to mean much to me, but here's what it put out:

#<Process::Status: pid=1132,exited(1)>


Mean something to you? Sorry to be so dense, but I'm used to Korn shell
scripting, where things seem less separated from the processes.
--
Posted via http://www.ruby-....

Thomas Luedeke

8/13/2008 9:01:00 PM

0

Robert Klemme wrote:
> On 13.08.2008 22:32, Thomas Luedeke wrote:
>>>> --
>>>
>>> What's the termination status in $?. That may tell you why your
>>> subprocess died.
>
>> I'm pretty new at this - what is the command to do so?
>
> Place a "p $?" in the line after your system command.
>
> On which platform and Ruby version are you? What shell are you using
> when executing the command directly?
>
> One effect of system you might not be aware of is that there will be a
> shell invoked if you use a single string. I have no idea whether this
> is related to your issue but it's certainly something to keep around in
> the back of your mind.
>
> Cheers
>
> robert


I'm running on HP UX-11, with ruby-1.8.7-p22. The underlying UNIX shell
is Korn shell.

See my last message for the results of the p $?.
--
Posted via http://www.ruby-....

Robert Klemme

8/14/2008 7:01:00 AM

0

2008/8/13 Thomas Luedeke <thomas.luedeke@areva.com>:

> I'm running on HP UX-11, with ruby-1.8.7-p22. The underlying UNIX shell
> is Korn shell.

Not Windows, that may make troubleshooting easier since on Windows
process handling is a bit different than on other systems.

> See my last message for the results of the p $?.

There was at least an error because exit code != 0. The meaning of
exit codes is usually to be found in the documentation of the program.

Did you see any messages on the console?

If not and if you have permissions you could try to invoke the ruby
interpreter with "strace" (redirect stderr to a file) and maybe find
something near the end of the output of strace.

Kind regards

robert

--
use.inject do |as, often| as.you_can - without end

?pam?ust?r

8/4/2012 12:51:00 AM

0

--
SPAMMED INTO IRRELEVANT CANADIAN NEWSGROUPS - AND CUT


"Kumbaya Flauerpower" <colo_tafa6@yahoo.co.uk> wrote in message
news:XnsA0A4160917B1ProggiesSuck@88.198.244.100...

--------Fri,-03-Aug-2012-00: 08:22 -0700 (PDT)
MIME-Version: 1.0
Path: not-for-mail
From: Kumbaya Flauerpower <colo_tafa6@yahoo.co.uk>
Newsgroups:
alt.california,alt.fan.rush-limbaugh,alt.global-warming,alt.politics.liberalism,can.politics
Subject: Re: CNBC: Obama's Unemployment rate really 20 % in many areas
Date: Fri, 3 Aug 2012 07:08:21 +0000 (UTC)
Organization: Proggie Peelers Anon
Lines: 101
Message-ID: <XnsA0A4160917B1ProggiesSuck@88.198.244.100>
References: <2GHSr.68607$iI7.9928@newsfe03.iad>
<5ea0caa5-46e3-4234-9e48-8f8b4a0a00e5@fj14g2000vbb.googlegroups.com>
Injection-Date: Fri, 3 Aug 2012 07:08:21 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
posting-host="51d2d332dfe965a9b30f74340b4d3b06";
logging-data="18651"; mail-complaints-to="abuse@eternal-september.org <<
============
"; posting-account="U2FsdGVkX190g99BT8bv0eCK4oOxVyja"
User-Agent: Xnews/5.04.25
Cancel-Lock: sha1:5KUuz4XMYqsMIDB/SnxTnXhIOzA=
X-Received-Bytes: 5343
Xref: Hurricane alt.california:869893 alt.fan.rush-limbaugh:4438153
alt.global-warming:813417 alt.politics.liberalism:1722737
can.politics:1413597