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]

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!

 

[Gerhard Fiedler]

(e-mail address removed) kirjutas:

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

 

[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]

@Paavo

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 path> is 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.

 

[Gerhard Fiedler]

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.)

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.aspx> seems to say that
double quotes (and a few other characters) are not allowed on Windows.

Gerhard

 

[Gerhard Fiedler]

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.aspx> seems 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