By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,086 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,086 IT Pros & Developers. It's quick & easy.

Issue related to system() call and file handles.

P: n/a
Okay, this one's a tough one for me to explain so this might take a few
e-mails to get the idea across. Here's what I got though.

I have this application running on a Sun/Solaris machine, written in
C, using the Sun Forte Developer 7 C 5.4 Compiler released a few years
ago. Not exactly old but, you get the picture.

Now, most if not all the file handles on this machine are most likely
being used up by a secondary process and/or application. I can't help
it, they are just gone. So for file manipuation I've been using open,
write, etc. The older file handle functions. No big deal, it works
fine.

But, I have a system() call, that doesn't exactly fail, it just
doesn't exactly 'work' properly. Here's the issue.

The command makes a call to an Oracle command called 'exp'. It's an
exporting application. Helps dump the database into a raw file. For
input, I have this script I make on the fly that calls this application
and feeds it commands to run properly and dump the desired contents.
One problem though, it seems like, the exp command, can't create the
appropreate file (Although it does make the file, it ends up a 0 length
file) and does nothing productive.

If I run the same script that my application generated though, thru a
second shell, the script works just fine. Even when the main
application that I've created is still running in the background.

So, why is it, when I call this script using system("./myScript"); it
fails, but when I manually run ./myScript it runs fine?

Any ideas?

Tony

Nov 14 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
gm********@yahoo.com writes:
Okay, this one's a tough one for me to explain so this might take a few
e-mails to get the idea across. Here's what I got though.

I have this application running on a Sun/Solaris machine, written in
C, using the Sun Forte Developer 7 C 5.4 Compiler released a few years
ago. Not exactly old but, you get the picture.

Now, most if not all the file handles on this machine are most likely
being used up by a secondary process and/or application. I can't help
it, they are just gone. So for file manipuation I've been using open,
write, etc. The older file handle functions. No big deal, it works
fine.
The open() and write() functions are non-standard (well, they're
POSIX, but the C standard doesn't mention them). To go slightly
off-topic, the standard C fopen() and fwrite() functions are often
implemented on top of the lower level open() and write() functions.
I'd be surprised if using the lower-level functions solved the problem
you're describing. But it's almost certainly a question for
comp.unix.solaris.

[snip]
So, why is it, when I call this script using system("./myScript"); it
fails, but when I manually run ./myScript it runs fine?


I doubt that we're going to be able to help you here, since it doesn't
sound like the problems you're having are related to anything defined
in the C language. Either comp.unix.solaris or comp.unix.programmer
is more likely to be able to help you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #2

P: n/a
gm********@yahoo.com wrote:
Okay, this one's a tough one for me to explain so this might take a few
e-mails to get the idea across. Here's what I got though.

I have this application running on a Sun/Solaris machine, written in
C, using the Sun Forte Developer 7 C 5.4 Compiler released a few years
ago. Not exactly old but, you get the picture.

Now, most if not all the file handles on this machine are most likely
being used up by a secondary process and/or application. I can't help
it, they are just gone. So for file manipuation I've been using open,
write, etc. The older file handle functions. No big deal, it works
fine.

But, I have a system() call, that doesn't exactly fail, it just
doesn't exactly 'work' properly. Here's the issue.

The command makes a call to an Oracle command called 'exp'. It's an
exporting application. Helps dump the database into a raw file. For
input, I have this script I make on the fly that calls this application
and feeds it commands to run properly and dump the desired contents.
One problem though, it seems like, the exp command, can't create the
appropreate file (Although it does make the file, it ends up a 0 length
file) and does nothing productive.

If I run the same script that my application generated though, thru a
second shell, the script works just fine. Even when the main
application that I've created is still running in the background.

So, why is it, when I call this script using system("./myScript"); it
fails, but when I manually run ./myScript it runs fine?

Any ideas?

Tony

This is not a C language issue but..

when you run .\myScript from the shell prompt, you get a 'new'
invocation to the shell to run it. Does 'system("./myScript")' invoke a
new shell? I don't know. Try 'system("sh ./myScript")' perhaps.

...but not a C language issue.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #3

P: n/a
Joe Wright <jo********@comcast.net> writes:
[...]
This is not a C language issue but..

when you run .\myScript from the shell prompt, you get a 'new'
invocation to the shell to run it. Does 'system("./myScript")' invoke
a new shell? I don't know. Try 'system("sh ./myScript")' perhaps.

..but not a C language issue.


<OT>
The Solaris man page for system ("man system") will answer this.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.