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

v3.3.1
open
Misc (42)
5
2008-12-22
2008-12-11
Yuji Yamano
No

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

Discussion

  • Leif Mortenson

    Leif Mortenson - 2008-12-22

    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

     
  • Leif Mortenson

    Leif Mortenson - 2008-12-22
    • assigned_to: nobody --> mortenson
     
  • Yuji Yamano

    Yuji Yamano - 2008-12-24

    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

    Leif Mortenson - 2008-12-25

    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

     

Log in to post a comment.