#211 wrapper.working.dir="C:\" doesn't work

[Yuji Yamano]

I can't start Java Service Wrapper with wrapper.working.dir="C:\" in Windows. C:\ and "C:\tmp" works well.

This problem was reported to Mule users mailinglist. See
http://www.nabble.com/mule.bat-does-not-work-on-Windows-XP-SP2-td20857802.html

You can reproduce the problem if you run TestWrapper.bat with the following patch.

C:\tmp\wrapper-windows-x86-32-3.3.1\bin>TestWrapper.bat
wrapper | Unable to set working directory to: C:\tmp\wrapper-windows-x86-32-3.3
.1\bin\" (The filename, directory name, or volume label syntax is incorrect. (0x
7b))
Press any key to continue . . .

--- TestWrapper.bat.orig 2008-08-17 10:40:50.000000000 -0700
+++ TestWrapper.bat 2008-12-10 11:37:09.984375000 -0800
@@ -57,7 +57,7 @@
rem Start the Wrapper
rem
:startup
-"%_WRAPPER_EXE%" -c %_WRAPPER_CONF%
+"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir="C:\"
if not errorlevel 1 goto :eof
pause

[Leif Mortenson]

Yuji,
I believe this is actually an issue with the way Windows parses batch files.

As you mentioned, removing the quotes appears to work correctly:
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir=C:\

It also works if you double up the '\':
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir="C:\\"

The problem is with the trailing '\'. You will have this same problem with any directory:
This works:
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir="C:\tmp"
This does not:
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir="C:\tmp\"

If your path ends with a '\' you should always double it up.

I believe Windows is attempting to allow you to escape the '"' so you can include it in your value. For example: "This is a \"test\""

Cheers,
Leif

[Yuji Yamano]

Leif,

Windows seems to be able to handle '\"' correctly.

C:\tmp>type foo.bat
@echo off
echo builtin echo: %1
c:/cygwin/bin/echo.exe cygwin echo: %1
C:\tmp>foo c:\
builtin echo: c:\
cygwin echo: c:\

C:\tmp>foo "c:\"
builtin echo: "c:\"
cygwin echo: c:\

C:\tmp>foo "c:\tmp\"
builtin echo: "c:\tmp\"
cygwin echo: c:\tmp\

[Leif Mortenson]

Yuji,
Thanks for your detailed test. I went back and retested this.

Using echo, you are correct. The echo program appears to handle this correctly.

However if I create a very simple little test program like the following, I see the behavior I explained before:
---
void main(int argc, char **argv) {
int j;
for (j = 0; j < argc; j++ ) {
printf( "argv[%d]=[%s]\n", j, argv[j]);
}
}
---
Here are a few test results:

1) Without quotes. Works fine
---
>foo.exe C:\ test
argv[0]=[foo.exe]
argv[1]=[C:\]
argv[2]=[test]
---

2) With quotes. Shows your problem.
---
>foo.exe "C:\" test
argv[0]=[foo.exe]
argv[1]=[C:" test]
---

3) With quotes and escaped back slash. Works fine
---
>foo.exe "C:\\" test
argv[0]=[foo.exe]
argv[1]=[C:\]
argv[2]=[test]
---

4) With quotes and unescaped back slash with trailing text. Works fine
---
>foo.exe "C:\bar" test
argv[0]=[foo.exe]
argv[1]=[C:\bar]
argv[2]=[test]
---

Echo is also an application, but I am not yet sure how that program works around this problem. The test above is very simple however. The parsing is being done by the operating system before the foo.exe process is even launched.

Cheers,
Leif

[Leif Mortenson]

Yuji,
This problem is described in the second comment here:
http://www.installaware.com/forum/viewtopic.php?t=2826&sid=b591a7ab30e3706c58174c0971f045b7

and here as well:
http://bytes.com/groups/net-c/238413-problem-environment-getcommandlineargs

It is a problem in the command line parser. The only solution would be for us to try and reparse the arguments being passed to the wrapper. But as you can see with my test cases, it would be difficult to reliably figure out what the correct parsing was after the fact.

This thread also describes this problem. But suggests an interesting solution.
http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/5ccd4bd0-46c0-424d-9842-ad8e0541747e/

Simply add a "." to the end of your path. Doing so will not change the meaning of the path.

5) With quotes and a trailing ".". Works fine
---
>foo.exe "C:\." test
argv[0]=[foo.exe]
argv[1]=[C:\.]
argv[2]=[test]
---

In the case of your original problem, this should make things work correctly:
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.working.dir="C:\."

Cheers,
Leif