calling system() with whitespaces

[tom_kuehnert]

Hi!

I'm trying to execute a program using system(). The program itself is
located in some path which might contain whitespaces.

Simple solution would be this:
system("\"C:\A B\C.exe\"");

but now this program also has parameters which need to be passed
(again with paths containing whitepaces)

I tried putting all paths in double quotes:
system("\"C:\A B\C.exe\" -a \"C:\A B\D.txt\"");

But it refuses to execute since "C:\A" is not a valid path.

Has anyone got an idea why this happens? Can I use single quotes
somehow to avoid this problem?
My guess is that system() just passes the whole line to cmd.exe as
parameter, putting the whole line in quotes. This then results in my
quotes closing those "too early".

I'd appreciate any help :)
Tom

PS: using VS005

[Ioannis Gyftos]

On Jun 24, 12:00*pm, [e-mail] wrote:

I tried putting all paths in double quotes:
system("\"C:\A B\C.exe\" -a \"C:\A B\D.txt\"");

Maybe you something like

system("C:\\\ B\\C.exe\\ -a C:\\A\ B\\D.txt");

(escape ' ' with '\ ' and '\' with '\\')

Then again, haven't tried something like that in ages.

[tom_kuehnert]

(Ups...forgot the double backslashes in this post (but they are there
in the code))

Mh...the '\ ' didn't work :/ VS complaines about it as an unknown
escape sequence.

Thanks for the reply!

[Paavo Helde]

to**********@gmx.de kirjutas:

Hi!

I'm trying to execute a program using system(). The program itself is
located in some path which might contain whitespaces.

Simple solution would be this:
system("\"C:\A B\C.exe\"");

but now this program also has parameters which need to be passed
(again with paths containing whitepaces)

I tried putting all paths in double quotes:
system("\"C:\A B\C.exe\" -a \"C:\A B\D.txt\"");

But it refuses to execute since "C:\A" is not a valid path.

Which one, the .exe or .txt? If it's .txt, then one has to blame C.exe
because he can't cope with filenames with spaces or quotes properly.

I understand you are working under Windows. In this case you should use
ShellExecute() or ShellExecuteEx(), these are Windows facilities for
calling the "shell". On Linux OTOH you could use proper escaping with
backslashes.

hth
Paavo

[Gerhard Fiedler]

On 2008-06-24 17:54:45, Paavo Helde wrote:

to**********@gmx.de kirjutas:

>I'm trying to execute a program using system(). The program itself is
located in some path which might contain whitespaces.

Simple solution would be this:
system("\"C:\A B\C.exe\"");

but now this program also has parameters which need to be passed
(again with paths containing whitepaces)

I tried putting all paths in double quotes:
system("\"C:\A B\C.exe\" -a \"C:\A B\D.txt\"");

But it refuses to execute since "C:\A" is not a valid path.

Which one, the .exe or .txt? If it's .txt, then one has to blame C.exe
because he can't cope with filenames with spaces or quotes properly.

Tom, does the command line you pass to system() run within cmd.exe? (Of
course the escape characters properly stripped.) That would be the first
test.

I understand you are working under Windows. In this case you should use
ShellExecute() or ShellExecuteEx(), these are Windows facilities for
calling the "shell".

Shouldn't system() do the same (with less control, of course)?

On Linux OTOH you could use proper escaping with backslashes.

Well... that this is more "proper" than enclosing the path in double quotes
is probably not a hard fact :)

Gerhard

[Paavo Helde]

Gerhard Fiedler <ge*****@gmail.comkirjutas:

On 2008-06-24 17:54:45, Paavo Helde wrote:

>to**********@gmx.de kirjutas:

>>I'm trying to execute a program using system(). The program itself
is located in some path which might contain whitespaces.

Simple solution would be this:
system("\"C:\A B\C.exe\"");

but now this program also has parameters which need to be passed
(again with paths containing whitepaces)

I tried putting all paths in double quotes:
system("\"C:\A B\C.exe\" -a \"C:\A B\D.txt\"");

But it refuses to execute since "C:\A" is not a valid path.

Which one, the .exe or .txt? If it's .txt, then one has to blame
C.exe because he can't cope with filenames with spaces or quotes
properly.

Tom, does the command line you pass to system() run within cmd.exe?
(Of course the escape characters properly stripped.) That would be the
first test.

>I understand you are working under Windows. In this case you should
use ShellExecute() or ShellExecuteEx(), these are Windows facilities
for calling the "shell".

Shouldn't system() do the same (with less control, of course)?

If it has less control it can't be the same ;-)

One thing: system() always creates a black DOS box on the screen which
many people do not like, even if it is the native Windows application
which is started (because CMD.EXE is a console application).

Also, the timing behavior of system() on Windows has been historically
different. I believe in earlier times system() returned immediately
without even waiting for the termination of the launched command.
Nowadays it seems to wait; one can use START inside the command to launch
an application asynchronously if that's what's wanted.

The advantage of system() in Unix world (compared with spawn/exec
families) is that one can use the exact same command line as in the
shell. In Windows the default shell is so poor, multiply patched over the
years and having hard to control deviations in behavior ("Command
Extensions"), so that using it does not buy much IMHO.

>On Linux OTOH you could use proper escaping with backslashes.

Well... that this is more "proper" than enclosing the path in double
quotes is probably not a hard fact :)

It is just easier to get right if the arguments may contain double quotes
or any other strange characters by themselves. And unknown directory
names most certainly can contain double quotes, for example.

All the best,
Paavo

[tom_kuehnert]

@Paavo

Which one, the .exe or .txt? If it's .txt, then one has to blame C.exe
because he can't cope with filenames with spaces or quotes properly.

Its already the C.exe which cannot be found...
And I wanted to use system() to stay on a level that could be used in
both - Windows and Linux (having to correct the slashes only).

@Gerhard

Tom, does the command line you pass to system() run within cmd.exe? (Of
course the escape characters properly stripped.) That would be the first
test.

I get a bit confused when trying to pass the argument directly to the
cmd.exe, since it opens just a new shell and seems to ignore the
parameters. I might be wrong with the assumption that the whole thing
is passed to cmd.exe as argument. This was just what I figured from
debugging into the system() command...

@ me

I gave up on the system() command by now and using spawn () now. This
allows me also an asynchronous operation which I need for another .exe
call a few lines later anyway... The command window produced by those
procedures isnt a problem since my 3D app has one of them itself and
output of the procedures called then appear in that one (at least
under windows).

Thanks for the advice from you all,
I will do some tests on the orignial problem when I've got some time
again - it still seems strange to me...

Thx+cu
Tom

[James Kanze]

On Jun 25, 9:16 am, [e-mail] wrote:

@Paavo

Which one, the .exe or .txt? If it's .txt, then one has to
blame C.exe because he can't cope with filenames with spaces
or quotes properly.

Its already the C.exe which cannot be found...
And I wanted to use system() to stay on a level that could be
used in both - Windows and Linux (having to correct the
slashes only).

There's no problem using slashes ('/') as directory separators
under both Windows and Linux; I'd generally recommend it, in
fact. The problems will be that the pathname itself won't be
the same; for historical reasons, Windows and Unix organize
their directories differently.

Beyond that, how system works is pretty much implementation
dependent. Posix requires that it execute:
execl(<shell path>, "sh", "-c", command, (char *)0);
(where <shell pathis the path to the Posix shell), but I
wouldn't be surprised if some implementations took the $SHELL
environment variable into account, or under Linux, simply
invoked bash as bash (and not as sh). Under Windows, it's even
more varied.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gerhard Fiedler]

On 2008-06-25 02:26:36, Paavo Helde wrote:

>>I understand you are working under Windows. In this case you should
use ShellExecute() or ShellExecuteEx(), these are Windows facilities
for calling the "shell".

Shouldn't system() do the same (with less control, of course)?

If it has less control it can't be the same ;-)

Yes, I expressed myself poorly -- but I guess you knew what I meant :)

One thing: system() always creates a black DOS box on the screen which
many people do not like, even if it is the native Windows application
which is started (because CMD.EXE is a console application).

I think that's what system() is for -- calling the shell. So this shouldn't
be surprising. (You're of course correct in that there is little point to
try to make it portable by calling system() because the details of the
shell will be varying widely -- on Linux not less than on Windows,
probably.)

>>On Linux OTOH you could use proper escaping with backslashes.

Well... that this is more "proper" than enclosing the path in double
quotes is probably not a hard fact :)

It is just easier to get right if the arguments may contain double quotes

That (arguments that may contain double quotes) would be a poor choice on
the side of the application developer. I'm not sure, but I think there's no
reliable way (if there is a way at all) to pass double quotes in arguments
through batch files. (But yes, that's a limitation with this scheme.)

or any other strange characters by themselves.

Is there a problem with "strange" characters (besides double quotes)?

And unknown directory names most certainly can contain double quotes, for
example.

Are you sure? This here
<http://msdn.microsoft.com/en-us/library/aa365247.aspxseems to say that
double quotes (and a few other characters) are not allowed on Windows.

Gerhard

[Paavo Helde]

Gerhard Fiedler <ge*****@gmail.comkirjutas:

On 2008-06-25 02:26:36, Paavo Helde wrote:

[...]

>

>And unknown directory names most certainly can contain double quotes,
for example.

Are you sure? This here
<http://msdn.microsoft.com/en-us/library/aa365247.aspxseems to say
that double quotes (and a few other characters) are not allowed on
Windows.

I was talking about Linux branch, sorry I was not clear enough. In Windows
quoting by backslashes does not work anyway. I think they invented some
other character for such quoting, but I don't remember right now what it
is.

Regards
Paavo

[Paavo Helde]

to**********@gmx.de kirjutas:

>
I get a bit confused when trying to pass the argument directly to the
cmd.exe, since it opens just a new shell and seems to ignore the
parameters.

It seems you are missing the /C parameter.

Regards
Paavo

[Gerhard Fiedler]

On 2008-06-25 13:42:45, Paavo Helde wrote:

Gerhard Fiedler <ge*****@gmail.comkirjutas:

>On 2008-06-25 02:26:36, Paavo Helde wrote:

[...]

>>

>>And unknown directory names most certainly can contain double quotes,
for example.

Are you sure? This here
<http://msdn.microsoft.com/en-us/library/aa365247.aspxseems to say
that double quotes (and a few other characters) are not allowed on
Windows.

I was talking about Linux branch, sorry I was not clear enough.

Under Linux, you'd generally use backslash quoting, so enclosing paths in
double quotes doesn't seem to apply.

In Windows quoting by backslashes does not work anyway. I think they
invented some other character for such quoting, but I don't remember
right now what it is.

I think the "proper" way to specify paths with spaces (and other characters
that may be interpreted otherwise) is to enclose them in double quotes.
Which works because double quotes are not allowed inside paths.

Gerhard

[tom_kuehnert]

>It seems you are missing the /C parameter.
Oops :)

Thx