Groovy
  1. Groovy
  2. GROOVY-2375

"groovy" launcher broken on Cygwin

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5
    • Fix Version/s: 1.5.1
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP SP2, Cygwin

      Description

      Running Groovy scripts on Cygwin when GROOVY_HOME contains spaces doesn't work anymore. The inclusion of the "-Dscript.name" (r4863) broke it (it worked fine up to r4241).

        Issue Links

          Activity

          Hide
          Daniel Serodio added a comment -

          The -Dscript.name argument is not correctly quoted, run {{ bash -x "$(which groovy)" }} and it'll be clear

          Show
          Daniel Serodio added a comment - The -Dscript.name argument is not correctly quoted, run {{ bash -x "$(which groovy)" }} and it'll be clear
          Hide
          Guillaume Delcroix added a comment -

          Any idea on how to fix this?

          Show
          Guillaume Delcroix added a comment - Any idea on how to fix this?
          Hide
          Daniel Serodio added a comment -

          Shell script quoting is a real pain in the neck. I gave it a try, and managed to fix "groovy" but break "groovysh", "groovyConsole", etc.
          I'll give it another try later.

          Show
          Daniel Serodio added a comment - Shell script quoting is a real pain in the neck. I gave it a try, and managed to fix "groovy" but break "groovysh", "groovyConsole", etc. I'll give it another try later.
          Hide
          Guillaume Delcroix added a comment -

          Ok, thanks, keep us posted on your progress.

          Show
          Guillaume Delcroix added a comment - Ok, thanks, keep us posted on your progress.
          Hide
          codex22 added a comment -

          There is another problem with the groovy launcher in 1.5.

          Arguments are not properly quoted, so that
          groovy -e "println 1"
          will cause an error (as groovy sees only println as argument which is not allowed).

          Other example:
          groovy -e "println(1)"
          works, but
          groovy -e "println (1)"
          does not (note the extra space).

          Should that be an issue on its own?
          I'm not sure why the cygwin startup scripts have been changed, seemed to work in 1.0.

          Show
          codex22 added a comment - There is another problem with the groovy launcher in 1.5. Arguments are not properly quoted, so that groovy -e "println 1" will cause an error (as groovy sees only println as argument which is not allowed). Other example: groovy -e "println(1)" works, but groovy -e "println (1)" does not (note the extra space). Should that be an issue on its own? I'm not sure why the cygwin startup scripts have been changed, seemed to work in 1.0.
          Hide
          Russel Winder added a comment -

          I think the -Dscript.name thing is solved simply by adding quotes around the parameter. Given that the problem is general and not just on Cygwin, i.e. it happens on Ubuntu, I can put in a fix – I will do this in the next few minutes.

          Of course if Daniel didn't use spaces in paths we wouldn't have a problem

          The command line scripts thing is a different problem, though almost certainly a quoting and/or backslash issue in startGroovy. I'll see if I can fix this at the same time.

          Show
          Russel Winder added a comment - I think the -Dscript.name thing is solved simply by adding quotes around the parameter. Given that the problem is general and not just on Cygwin, i.e. it happens on Ubuntu, I can put in a fix – I will do this in the next few minutes. Of course if Daniel didn't use spaces in paths we wouldn't have a problem The command line scripts thing is a different problem, though almost certainly a quoting and/or backslash issue in startGroovy. I'll see if I can fix this at the same time.
          Hide
          Russel Winder added a comment -

          Given that the string script.name only appears in the groovy script and nowhere else, this would seem to imply that it serves no useful purpose. The ideal fix appears to be to remove it from the groovy script. The question is then why did it get put in in the first place. And why only in there and not the other scripts.

          I see that there is also occurrences of it in the Windows batch scripts but that will have to be someone else's problem.

          Show
          Russel Winder added a comment - Given that the string script.name only appears in the groovy script and nowhere else, this would seem to imply that it serves no useful purpose. The ideal fix appears to be to remove it from the groovy script. The question is then why did it get put in in the first place. And why only in there and not the other scripts. I see that there is also occurrences of it in the Windows batch scripts but that will have to be someone else's problem.
          Hide
          Russel Winder added a comment -

          By doing a trivial but subtle rearrangement in the ARGUMENTS processing in startGroovy, I think I have circumvented (not fixed) Michael's problem. I suspect though that there are new space problems that will haunt us.

          I am still not sure there is a quoting of the -Dscript.name that fixes Daniel's problem.

          Show
          Russel Winder added a comment - By doing a trivial but subtle rearrangement in the ARGUMENTS processing in startGroovy, I think I have circumvented (not fixed) Michael's problem. I suspect though that there are new space problems that will haunt us. I am still not sure there is a quoting of the -Dscript.name that fixes Daniel's problem.
          Hide
          Daniel Serodio added a comment -

          Russel, you'll have to blame Bill for the spaces in filenames . I guess M$ got so carried away by the possibility of having spaces in filenames that they put them everywhere they could.
          "C:\Programs" or "Applications" would be much better, but they had to use a long name and put a space there. Same for "Documents and Settings" (which BTW, because "Users" in Vista).

          </rant>

          I think I've fixed it, by undoing the mentioned change, defining a SCRIPT_NAME=$0 variable in groovy and adding -Dscript.name=$SCRIPT_NAME to startGroovy, but I'll have to test some more.

          Should I create a patch? Against which version?

          Show
          Daniel Serodio added a comment - Russel, you'll have to blame Bill for the spaces in filenames . I guess M$ got so carried away by the possibility of having spaces in filenames that they put them everywhere they could. "C:\Programs" or "Applications" would be much better, but they had to use a long name and put a space there. Same for "Documents and Settings" (which BTW, because "Users" in Vista). </rant> I think I've fixed it, by undoing the mentioned change, defining a SCRIPT_NAME=$0 variable in groovy and adding -Dscript.name=$SCRIPT_NAME to startGroovy , but I'll have to test some more. Should I create a patch? Against which version?
          Hide
          Russel Winder added a comment -

          It seems I was over confident of my little hack to cure the "println 1" problem. It is back. I shall work on it more though.

          Show
          Russel Winder added a comment - It seems I was over confident of my little hack to cure the "println 1" problem. It is back. I shall work on it more though.
          Hide
          Russel Winder added a comment -

          I just tried your idea and it works like a charm, In fact, I think removing the setting of the JAVA_OPTS from the groovy scripts and then putting SCRIPT_PATH="$0" in startGroovy and then the -D line in the exec statement, provides a solution for all the scripts.

          I shall commit this and then see if I embarrass myself again

          Show
          Russel Winder added a comment - I just tried your idea and it works like a charm, In fact, I think removing the setting of the JAVA_OPTS from the groovy scripts and then putting SCRIPT_PATH="$0" in startGroovy and then the -D line in the exec statement, provides a solution for all the scripts. I shall commit this and then see if I embarrass myself again
          Hide
          Russel Winder added a comment -

          I have reverted a refactoring and fiddled a bit and now all the cases listed here seem to work as they should. I suspect though that there are many more issues left to find in teh case of Cygwin. The problem is all the parameter processing that goes on to try and convert path names.

          Show
          Russel Winder added a comment - I have reverted a refactoring and fiddled a bit and now all the cases listed here seem to work as they should. I suspect though that there are many more issues left to find in teh case of Cygwin. The problem is all the parameter processing that goes on to try and convert path names.

            People

            • Assignee:
              Russel Winder
              Reporter:
              Daniel Serodio
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development