Use of System function

[BHARAT MEHTA]

Hi Guys,
I am little new to C. I wish to know the way to use the 'system'
function. I mean I know that the function is used to run an external
DOS command but every time I use it it returns -1 which meansthe
command could not be executed.
Kindly help me............

 

[Ralph A. Moritz]

Hi Guys,
I am little new to C. I wish to know the way to use the 'system'
function. I mean I know that the function is used to run an external
DOS command but every time I use it it returns -1 which meansthe
command could not be executed.

system() uses the shell (COMMAND.COM on DOS/Windows, /bin/sh
on Unix) to execute the specified command. If you just give a program
name such as `unzip', then `unzip' must be in a directory specfied in
the PATH environment variable. To be sure, use an absolute path to
the executable, eg.

system("/usr/games/fortune");
system("C:\Program Files\Winzip\wzip32.exe");

Some systems may have no notion of a shell. For those, system()
is a no-op. You can check for the presence of a shell by calling
system() with an argument of NULL, and checking the return value.
If non-zero, a shell is available.

HTH,
Ralph

 

[osmium]

system() uses the shell (COMMAND.COM on DOS/Windows, /bin/sh
on Unix) to execute the specified command. If you just give a program
name such as `unzip', then `unzip' must be in a directory specfied in
the PATH environment variable. To be sure, use an absolute path to
the executable, eg.

system("/usr/games/fortune");
system("C:\Program Files\Winzip\wzip32.exe");

If that second one doesn't work check up on escape sequences WRT the '\'
character..

 

[Rod Pemberton]

If that second one doesn't work check up on escape sequences WRT the '\'
character..

The second one does work and is correct for MS-DOS. The string in system()
passed directly to the OS's command processor _AS_IS_. For the MS-DOS
command.com command line, one does not need to escape the backslash '\'
character as you would for printf().

 

[Jordan Abel]

The second one does work and is correct for MS-DOS. The string in system()
passed directly to the OS's command processor _AS_IS_. For the MS-DOS
command.com command line, one does not need to escape the backslash '\'
character as you would for printf().

Eh?

You _always_ need to escape the backslash when it appears in a string
literal. It's not printf that interprets it, it's the compiler. It's not
like a % sequence.

 

[Keith Thompson]

The second one does work and is correct for MS-DOS. The string in system()
passed directly to the OS's command processor _AS_IS_. For the MS-DOS
command.com command line, one does not need to escape the backslash '\'
character as you would for printf().

Wrong. (Did you actually try it?)

The argument to system() is a string literal, and is interpreted
according to C's rules for string literals. The fact that it's an
argument to system() is irrelevant.

Since the language doesn't define the escape sequences \P, \W, or \w,
strictly speaking the argument isn't even a valid token, and a
diagnostic is required. After the diagnostic is issued, the compiler
can do anything it likes, including rejecting the program. It could
conceivably treat "\P" as equivalent to "\\P", but that would be a bad
idea, since it's not allowed to mess with \a, \b, \f, \n, \r, \t, or \v.

(The rules are more lax for #include directives, since in
#include "foobar.h"
the "foobar.h" isn't actually a string literal.)

 

[Rod Pemberton]

Wrong. (Did you actually try it?)

I have existing code which does the same thing (which I which consulted
prior to my post). No escapes are needed and it works with multiple DOS
based compilers.

The argument to system() is a string literal, and is interpreted
according to C's rules for string literals. The fact that it's an
argument to system() is irrelevant.

Apparently not. I haven't checked the ISO spec., but Harbison and Steele
agrees with me that the string from system() is passed as is to the OS in an
implementation defined manner.

 

[Rod Pemberton]

Eh?

You _always_ need to escape the backslash when it appears in a string
literal. It's not printf that interprets it, it's the compiler. It's not
like a % sequence.

See my reply to Keith.

 

[Keith Thompson]

"Ralph A. Moritz" writes: [...]
system("/usr/games/fortune");
system("C:\Program Files\Winzip\wzip32.exe");

If that second one doesn't work check up on escape sequences WRT the '\'
character..

The second one does work and is correct for MS-DOS. The string in system()
passed directly to the OS's command processor _AS_IS_. For the MS-DOS
command.com command line, one does not need to escape the backslash '\'
character as you would for printf().

Eh?

You _always_ need to escape the backslash when it appears in a string
literal. It's not printf that interprets it, it's the compiler. It's not
like a % sequence.

You're right, printf doesn't interpret the argument to system(). }

 

[Keith Thompson]

"Ralph A. Moritz" writes: [...]
system("/usr/games/fortune");
system("C:\Program Files\Winzip\wzip32.exe");

If that second one doesn't work check up on escape sequences WRT
the '\' character..

The second one does work and is correct for MS-DOS. The string
in system() passed directly to the OS's command processor
_AS_IS_. For the MS-DOS command.com command line, one does not
need to escape the backslash '\' character as you would for
printf().

Wrong. (Did you actually try it?)

I have existing code which does the same thing (which I which consulted
prior to my post). No escapes are needed and it works with multiple DOS
based compilers.

If so, the compilers in question may be providing an extension. If
they don't produce a diagnostic, they're non-conforming.

Show us a complete and self-contained C program that supports your
claim. For example:

#include <stdlib.h>
int main(void)
{
system("...");
return 0;
}

where "..." is replaced with whatever you like. Make sure it actually
works with some MS-DOS compiler (and tell us which one).

If you're able to do that, see what happens if the argument contains
one of the standard escape sequences: \a \b \f \n \r \t \v. If any of
those is interpreted as something other than an alert, backspace, form
feed, new line, carriage return, horizontal tab, or vertical tab
charater, respectively, then your compiler is broken.

Apparently not. I haven't checked the ISO spec.,

I suggest you do so.

but Harbison and
Steele agrees with me that the string from system() is passed as is
to the OS in an implementation defined manner.

You've misinterpreted Harbison and Steele. The string argument is
passed to the operating system's command processor for execution in
some implementation-defined way, but any implementation-defined
behavior occurs only after the string is passed to system(). The
evaluation of the argument expression is not affected by the fact that
it's in a call to system().

This:

"C:\Program Files\Winzip\wzip32.exe"

is not a valid C token (except possibly in a #include directive).

 

[Jordan Abel]

Wrong. (Did you actually try it?)

The argument to system() is a string literal, and is interpreted
according to C's rules for string literals. The fact that it's an
argument to system() is irrelevant.

Since the language doesn't define the escape sequences \P, \W, or \w,
strictly speaking the argument isn't even a valid token, and a
diagnostic is required. After the diagnostic is issued, the compiler
can do anything it likes, including rejecting the program. It could
conceivably treat "\P" as equivalent to "\\P", but that would be a bad
idea, since it's not allowed to mess with \a, \b, \f, \n, \r, \t, or
\v.

Even in a string literal that also contains \P? suppose "\P" is defined
by the implementation as "expand to \P and cause all other escapes in
the string literal not to be interpreted"

 

[Jordan Abel]

I have existing code which does the same thing (which I which
consulted prior to my post). No escapes are needed and it works with
multiple DOS based compilers.

So they choose to define the escape \P as expanding to \\P. they have
that right.

Apparently not. I haven't checked the ISO spec., but Harbison and Steele
agrees with me that the string from system() is passed as is to the OS in an
implementation defined manner.

You misunderstand what "as is" really means.

 

[Jordan Abel]

See my reply to Keith.

You misunderstand what "the string" means in the statement you cited.
"the string" means the sequence of characters AFTER the string literal
token has had escapes substituted for control characters.

 

[Keith Thompson]

Even in a string literal that also contains \P? suppose "\P" is defined
by the implementation as "expand to \P and cause all other escapes in
the string literal not to be interpreted"

A diagnostic is required for a token containing \P that otherwise
looks like a string literal. Once the diagnostic is issued, the
compiler is free to accept the program; the behavior is then undefined
(even if the implementation documents the behavior, it's still
"undefined behavior" as the C standard defines the term).

So yes, an implementation could behave as you describe. I don't
believe that's what's happening here. The \P appears merely because
the program refers to a file under the <C:\Program Files> directory
(folder, whatever).

 

[Keith Thompson]

So they choose to define the escape \P as expanding to \\P. they have
that right.

What do you mean by "right"? There is no "right" expansion for \P in
a string literal.

If the compiler is behaving as you suggest, what would you expect it
to do for:

system("C:\foo\bar\foobar.exe");

? If it converts "\f" to anything other than a form feed, or "\b" to
anything other than a backspace, it's broken. (Conceivably the
system() function could be doing silly things like translating a form
feed character to a backslash-f sequence; presumably fopen() and a
host of other library functions would have to do the same thing.) And
how would you pass an actual horizontal tab character to system()

See question 19.17 in the FAQ, <http://www.c-faq.com/osdep/dospath.html>.
It also mentions (somewhat off-topically) that MS-DOS also accepts '/'
characters as directory separators; perhaps that's the source of the
confusion?

I suggest waiting for Rod Pemberton to demonstrate the actual behavior
he's talking about -- or, better yet, for someone else to do so.
Speculating about extensions that some DOS compiler *might* provide
doesn't seem useful.

 

[Jordan Abel]

What do you mean by "right"? There is no "right" expansion for \P in
a string literal.

I mean the right they have to do it, which they are exercising.

 

[Keith Thompson]

I mean the right they have to do it, which they are exercising.

Ok, I misunderstood; I thought you meant "they have that correct".

(But I've seen no real evidence so far that they really are exercising
that right.)