slice2cs commandline parsing issue

[kwaclaw]

It seems that on Windows, slice2cs has issues parsing file paths that have spaces *and* back-slashes in them. For example, this command line gives me the error "input files must end with '.ice':

"%ICE_HOME%\bin\slice2cs.exe" -I"C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\" -I%ICE_HOME%\slice --output-dir "C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\StateServer\generated" "C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\Services.ice" "C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\StorageServices.ice"

However, if I replace all back-slashes with forward-slashes, the error goes away. It looks as if with back-slashes the spaces are interpreted as command line delimiters (even though the paths are enclosed in quotes).

The issue seems limited to the -I parameter, as the error also goes away if the include directories in the command line above don't contain spaces.

This is especially a problem when I am running this as a build event under VS 2005 because the paths are build macros that are not under my control.

Karl

[michi]

Hi Karl,

slice2cs (and all the other command-line tools) apply the exact same quoting and escaping rules as bash. When you have something like

-I"C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\"

bash quoting rules say that, within double quotes, only backslash retains its special meaning, that is, within double quotes, \" is an escaped double quote (so it doesn't close the string and you end up with a double quote), \\ is a single literal backslash, and \<newline> is an literal newline.

Bash does not specify what happens if, within double quotes, a backslash is followed by any other character. However, what every implementation of bash I tried does (and what Ice does) is to preserve both the backslash and the character following it so, for example, \D is preserved literally and results in \D in the output string.

I suspect that, in your example, the problem is caused by the quote following the include path:

-I"C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\" -I%ICE_HOME%\slice --output-dir "C:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE\StateServer\generated"

Here, we have \" at the end of the first -I option. What that will do is result in a literal double quote (without the backslash) in the output string, so the above turns into:

-IC:\Documents and Settings\Karl\Desktop\Java Web Services\IS2ICE" -I%ICE_HOME%\slice --output-dir (with a trailing space)

C:\Documents

and

Settings\Karl\Desktop\Java Web Services\IS2ICE\StateServer\generated

I have placed each string onto a separate line to show how the option parser will break up these strings into the separate elements of argv.

Of course, that explains the complaint from the compiler because any string that doesn't start with - or -- is taken not to be a command-line option, but a file argument, so the compiler ends up looking for source files such as and and C:\Documents. The compiler then complains that these file names do not end in .ice and, hence, are not legal input file names.

When you replace the backslashes with forward slashes, the problem goes away because this prevents the double quote at the end of IS2ICE\" from being taken literally, and the entire string parses and is split into command-line arguments correctly.

I'm not entirely sure what we can do to help with this. The problems with the different path separators and quoting rules in Windows and Unix are an endless source of grief, and I suspect that there is no one true way that would solve this problem completely.

One way around your problem would be to replace the double quotes with single quotes. Within single quotes, double quotes (and everything else, except for a single quote) are taken literally, so that would prevent the closing double quote from causing the problem. Is this a possible option for you?

Cheers,

Michi.

[kwaclaw]

Hi Karl,

One way around your problem would be to replace the double quotes with single quotes. Within single quotes, double quotes (and everything else, except for a single quote) are taken literally, so that would prevent the closing double quote from causing the problem. Is this a possible option for you?

Cheers,

Michi.

Hi Michi,

I tried the single quotes, but it seems slice2cs does not honor the include directory then. I tried this on my work PC, where i did not have spaces in my path, but it still didn't work, specifically:

The expanded (from VS macro) include path would be C:\Data\PBS\IS2ICE\, so -IC:\Data\PBS\IS2ICE\ works, but with -I'C:\Data\PBS\IS2ICE\' slice2cs does not find the included files.

However, I found an ugly looking way that seems to work: I keep using double quotes, but before the closing double quote I append another back-slash, so the expanded path would end with \\", which will turn into \" when slice2cs parses the command line. Maybe this (or another, better) solution should be added to the docs for the benefit of Windows users.

Karl

[michi]

Hi Karl,

I tried the single quotes, but it seems slice2cs does not honor the include directory then.

Hmmm... Not sure what's going on there. Thanks for letting me know, I'll have a look today.

However, I found an ugly looking way that seems to work: I keep using double quotes, but before the closing double quote I append another back-slash, so the expanded path would end with \\", which will turn into \" when slice2cs parses the command line.

Yes, that will work. The two backslashes turn into a single literal backslash, and the double quote the retains its meaning as a string delimiter.

Maybe this (or another, better) solution should be added to the docs for the benefit of Windows users.

Thanks, I'll have a look at what we can do to improve things there.

Cheers,

Michi.

[michi]

The expanded (from VS macro) include path would be C:\Data\PBS\IS2ICE\, so -IC:\Data\PBS\IS2ICE\ works, but with -I'C:\Data\PBS\IS2ICE\' slice2cs does not find the included files.

Ah, sorry, this suffers essentially the same problem:

-I'C:\Data\PBS\IS2ICE\'

The problem here is the \' at the end, which escapes the single quote and produces a literal single quote in the output string.

Basically, to make things work, you have to either avoid a backslash immediately preceding a single or double quote, or replace the backslash preceding a single or double quote with a double backslash, as you mentioned in your earlier post.

Cheers,

Michi.