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

Regarding system function

P: n/a
Hi All,

Please have a look the below program

#include<stdlib.h>
int i = system("pwd");

I compiled the above program in UNIX ,it got compiled and
executed with out any errors.It prints the present working directory.Am
having certain doubts about this program.

1) without main how it got executed
2)is the system funcion is static
3) is the shell had executed that system command

if i write simply
#include<stdlib.h>
system("pwd")
it's thwoing errors at compilation stage

4) how return type is playing a role,is it mandatory
to collect the return type in C(upto my knowledge it's not mandatory to
collect the return type).

In case of any queries please revert me back.

Regards
Sunil

Oct 6 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
"sunil" <su*******@gmail.comwrote:
#include<stdlib.h>
int i = system("pwd");

I compiled the above program in UNIX ,it got compiled and
executed with out any errors.
Well, that's wrong, then. Time to hitch up the warning level on your
compilations, or to stop compiling GNU almost-but-not-quite-C.

From the Standard, paragraph 6.7.8, item 4: "All the expressions in an
initializer for an object that has static storage duration shall be
constant expressions or string literals". A function call is not a
constant expression or a string literal; therefore, this code is not
correct C.
It prints the present working directory.Am
having certain doubts about this program.

1) without main how it got executed
It shouldn't have been.
2)is the system funcion is static
That does not make sense. Objects can have static duration; functions
just _are_.
3) is the shell had executed that system command
Well, yes, of course. That's what system() is for, after all.
4) how return type is playing a role,is it mandatory
to collect the return type in C(upto my knowledge it's not mandatory to
collect the return type).
No.
In case of any queries please revert me back.
Yer_what_? "Please revert me back"? Ok, if you say so... If someone
sends in a query I'll ditch today's version of you and go back to the
backup you made yesterday.

Richard
Oct 6 '06 #2

P: n/a
Richard Bos wrote:
"sunil" <su*******@gmail.comwrote:

>>#include<stdlib.h>
int i = system("pwd");

I compiled the above program in UNIX ,it got compiled and
executed with out any errors.


Well, that's wrong, then. Time to hitch up the warning level on your
compilations, or to stop compiling GNU almost-but-not-quite-C.

From the Standard, paragraph 6.7.8, item 4: "All the expressions in an
initializer for an object that has static storage duration shall be
constant expressions or string literals". A function call is not a
constant expression or a string literal; therefore, this code is not
correct C.

>>It prints the present working directory.Am
having certain doubts about this program.

1) without main how it got executed


It shouldn't have been.

> 2)is the system funcion is static


That does not make sense. Objects can have static duration; functions
just _are_.

> 3) is the shell had executed that system command


Well, yes, of course. That's what system() is for, after all.

> 4) how return type is playing a role,is it mandatory
to collect the return type in C(upto my knowledge it's not mandatory to
collect the return type).


No.

>>In case of any queries please revert me back.


Yer_what_? "Please revert me back"? Ok, if you say so... If someone
sends in a query I'll ditch today's version of you and go back to the
backup you made yesterday.

Richard
What is more mysterious is that the function calls "pwd".

But this will be the pwd where the COMPILER is, since the
compiler calls "pwd". It will NOT be the directory where
the program will be since the poor program is not even compiled yet!
Oct 6 '06 #3

P: n/a

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45***************@news.xs4all.nl...
"sunil" <su*******@gmail.comwrote:
#include<stdlib.h>
int i = system("pwd");

I compiled the above program in UNIX ,it got compiled and
executed with out any errors.

Well, that's wrong, then. Time to hitch up the warning level on your
compilations, or to stop compiling GNU almost-but-not-quite-C.
No reason to pick on GCC. The very old version of GCC I'm using, gives a
warning and fails to compiler _without_ any extra options such as '-Wall' or
'-pedantic'.
Rod Pemberton
Oct 6 '06 #4

P: n/a

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
Richard Bos wrote:
"sunil" <su*******@gmail.comwrote:

>#include<stdlib.h>
int i = system("pwd");

What is more mysterious is that the function calls "pwd".

But this will be the pwd where the COMPILER is, since the
compiler calls "pwd". It will NOT be the directory where
the program will be since the poor program is not even compiled yet!
Jacob?

He stated that "pwd - print working directory" is either a shell command or
an equivalent external previously compiled program. It isn't the snippet he
posted. I don't believe his program works, but if does work as claimed,
system() would attempt to execute "pwd" when the program is run. It may not
find "pwd" on the default directories. It may or may not preference the
shell command over an executable of the same name. etc...
Rod Pemberton
Oct 6 '06 #5

P: n/a
Rod Pemberton wrote:
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
>>Richard Bos wrote:
>>>"sunil" <su*******@gmail.comwrote:

#include<stdlib.h>
int i = system("pwd");

What is more mysterious is that the function calls "pwd".

But this will be the pwd where the COMPILER is, since the
compiler calls "pwd". It will NOT be the directory where
the program will be since the poor program is not even compiled yet!


Jacob?

He stated that "pwd - print working directory" is either a shell command or
an equivalent external previously compiled program. It isn't the snippet he
posted.
Ahh OK, I misunderstood. I thought that under GNU at global level:

int i = system("pwd");

would be executed at compile time, like

double p = sqrt(47.8);
I don't believe his program works, but if does work as claimed,
system() would attempt to execute "pwd" when the program is run. It may not
find "pwd" on the default directories. It may or may not preference the
shell command over an executable of the same name. etc...
Rod Pemberton

Oct 6 '06 #6

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Rod Pemberton wrote:
>"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr.. .
>>>Richard Bos wrote:
"sunil" <su*******@gmail.comwrote:

>#include<stdlib.h>
>int i = system("pwd");

What is more mysterious is that the function calls "pwd".

But this will be the pwd where the COMPILER is, since the
compiler calls "pwd". It will NOT be the directory where
the program will be since the poor program is not even compiled yet!
Jacob?
He stated that "pwd - print working directory" is either a shell
command or
an equivalent external previously compiled program. It isn't the snippet he
posted.

Ahh OK, I misunderstood. I thought that under GNU at global level:

int i = system("pwd");

would be executed at compile time, like

double p = sqrt(47.8);
Um, no. Function calls happen during execution; they can be optimized
away and evaluated during compilation only if the compiler can prove
that it makes no difference to the result or side effects. The
compiler (if it's sufficiently clever) knows what sqrt() does, and
knows that it has no side effects and depends only on the value of its
argument. No such optimization is possible for system().

Don't take this personally, but I have no idea how you could have
gotten the idea that system("pwd") could be evaluated during
compilation. (I trust your own compiler doesn't try to do this.)

(By "GNU" you mean "gcc", yes?)

--
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.
Oct 6 '06 #7

P: n/a
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
>>Rod Pemberton wrote:
>>>"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr.. .

Richard Bos wrote:

>"sunil" <su*******@gmail.comwrote:
>
>
>>#include<stdlib.h>
>>int i = system("pwd");

What is more mysterious is that the function calls "pwd".

But this will be the pwd where the COMPILER is, since the
compiler calls "pwd". It will NOT be the directory where
the program will be since the poor program is not even compiled yet!

Jacob?
He stated that "pwd - print working directory" is either a shell
command or
an equivalent external previously compiled program. It isn't the snippet he
posted.

Ahh OK, I misunderstood. I thought that under GNU at global level:

int i = system("pwd");

would be executed at compile time, like

double p = sqrt(47.8);


Um, no. Function calls happen during execution; they can be optimized
away and evaluated during compilation only if the compiler can prove
that it makes no difference to the result or side effects. The
compiler (if it's sufficiently clever) knows what sqrt() does, and
knows that it has no side effects and depends only on the value of its
argument. No such optimization is possible for system().

Don't take this personally, but I have no idea how you could have
gotten the idea that system("pwd") could be evaluated during
compilation. (I trust your own compiler doesn't try to do this.)

(By "GNU" you mean "gcc", yes?)
We had:

#include<stdlib.h>
int i = system("pwd");

I have been playing with the idea since a long time of allowing
global level initializations evaluated at run time.

For instance
double k = log(2);
instead of
double k = 0.693147180559945309417232121;

I haven't implemented this because (precisely) there are
functions that would make problems, "system" being one of
them, or even

double d = get_number("Value of d for this compilation");

When I saw that "program", I coumld not immediately interpret it,
and somehow I thought that my extensions ideas were implemented
already under GNU, what left me quite impressed.

Apparently I misunderstood. They will put those into their
C++ .ini sections probably, and the functions get called
like the constructors of C++.

Does this satisfy your curiosity?

jacob
Oct 6 '06 #8

P: n/a
jacob navia wrote:
I have been playing with the idea since a long time of allowing
global level initializations evaluated at run time.

DAMM!!!!
not run time but COMPILE TIME sorry.
Oct 6 '06 #9

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Keith Thompson wrote:
>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>>>Ahh OK, I misunderstood. I thought that under GNU at global level:

int i = system("pwd");

would be executed at compile time, like

double p = sqrt(47.8);
Um, no. Function calls happen during execution; they can be
optimized
away and evaluated during compilation only if the compiler can prove
that it makes no difference to the result or side effects. The
compiler (if it's sufficiently clever) knows what sqrt() does, and
knows that it has no side effects and depends only on the value of its
argument. No such optimization is possible for system().
Don't take this personally, but I have no idea how you could have
gotten the idea that system("pwd") could be evaluated during
compilation. (I trust your own compiler doesn't try to do this.)
(By "GNU" you mean "gcc", yes?)

We had:

#include<stdlib.h>
int i = system("pwd");

I have been playing with the idea since a long time of allowing
global level initializations evaluated at run time.

For instance
double k = log(2);
instead of
double k = 0.693147180559945309417232121;

I haven't implemented this because (precisely) there are
functions that would make problems, "system" being one of
them, or even

double d = get_number("Value of d for this compilation");

When I saw that "program", I coumld not immediately interpret it,
and somehow I thought that my extensions ideas were implemented
already under GNU, what left me quite impressed.

Apparently I misunderstood. They will put those into their
C++ .ini sections probably, and the functions get called
like the constructors of C++.

Does this satisfy your curiosity?
Yes it does; thank you for clearing this up.

I had missed the fact that the declaration
int i = system("pwd");
was outside any function, and that i is therefore of static storage
duration.

In standard C, "all the expressions in an initializer for an object
that has static storage duration shall be constant expressions or
string literals", i.e., they must be evaluable at compile time. That
explains why you assumed that the initializer for a static object must
be evaluated at compile time even if (as an extension) it's not a
constant expression. I wouldn't have made that assumption myself (for
one thing, consider cross-compilers), but it's understandable.

--
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.
Oct 6 '06 #10

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
jacob navia wrote:
>I have been playing with the idea since a long time of allowing
global level initializations evaluated at run time.

DAMM!!!!
not run time but COMPILE TIME sorry.
Really? Global level initializations are normally evaluated at
compile time. Allowing them at run time might be an interesting
extension. Your initial statement made sense.

If you're talking about evaluating things like system("pwd") at
compile time, that just seems counterintuitive and not particularly
useful. If you really want to provide a feature like that, I suggest
doing it via some special construct that makes it clear what's
happening, perhaps:

int i = __COMPILE_TIME__(system("pwd"));

It would never have occured to me that, without such a marker, the
system() call would be evaluted before the program's actual execution,
and I suspect most programmers would make the same assumption I do.

--
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.
Oct 6 '06 #11

P: n/a
sunil wrote:
Please have a look the below program

#include<stdlib.h>
int i = system("pwd");

I compiled the above program in UNIX ,it got compiled and
executed with out any errors.It prints the present working directory.Am
having certain doubts about this program.

1) without main how it got executed
I can't explain this; a program without a main function will not link
under any of the compiler systems I have here (including with GCC, the
most common C compiler on Unix systems).

I'm very curious to know what compiler will produce an executable for
your program.

C++ compilers will _compile_ your program fine, as it is allowed for you
to use non-constant initialisers. The system() function would be called
during program initialisation stage, before main function starts executing.

But most systems won't link it into an executable without a main
function (or other implementation specific form, like WinMain).

--
Simon.
Oct 8 '06 #12

P: n/a
"Rod Pemberton" <do*********@bitfoad.cmmwrote:
>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45***************@news.xs4all.nl...
"sunil" <su*******@gmail.comwrote:
#include<stdlib.h>
int i = system("pwd");
>
I compiled the above program in UNIX ,it got compiled and
executed with out any errors.
Well, that's wrong, then. Time to hitch up the warning level on your
compilations, or to stop compiling GNU almost-but-not-quite-C.

No reason to pick on GCC. The very old version of GCC I'm using, gives a
warning and fails to compiler _without_ any extra options such as '-Wall' or
'-pedantic'.
And newer versions? Really, I can't imagine any other compiler which
would compile that code without special options, on Unix. MS C++## might
do it, but it would result in "Bad command or file name".

Richard
Oct 9 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.