Bob,

I have taken the liberty of circulating this very widely since I think
it is a an issue that affects the whole Groovy milieu.

I now use only Ubuntu (mostly), Mac OS X (sometimes), and Solaris
(occasionally), and have no Windows capability, not even using
VirtualBox on Ubuntu.  I am therefore not in a position to test, try or
experiment with the Gant Windows launch scripts.  I appreciate that
there are many out there who do use Windows and actually want them to
work, I'm afraid some of those people will have to provide the love to
the Windows specific components of Gant.

In fact, the Gant launch scripts are very minor variations of the Groovy
ones -- and I think Gradle is more or less in the same boat.  I am
guessing that either the problems are in the few minor variations (and
hence Gant specific) or they affect all the Groovy-related systems.

I wonder if there needs to be a "cross-cutting" launch scripts activity
(both for the Posix shell scripts and the Windows batch files) that
works in harmony with the native launcher and provides consistent and
working launch scripts for any and all Groovy-related systems?


On Sat, 2009-08-01 at 22:19 +1000, Bob Brown wrote:
> Congrats on getting Gant 1.7.0 out!
> 
> I think I have a bug...
> 
> I have win7/64-bit.
> 
> My path contains 
> 
> ...;C:\Program Files (x86)\PC Connectivity Solution\;...
> 
> The new gant.bat file has:
> 
> set GROOVY_HOME=%GANT_HOME%
> 
> @rem  If ANT_HOME is not set, deduce a path -- this is needed in order to
> discover the location of the jars
> @rem  asscoiated with the Ant installation.
> 
> if not "%ANT_HOME%" == "" goto endSetAntHome
>    for %%P in ( %PATH% ) do if exist %%P\ant.bat set ANT_HOME=%%P\..
>    if not "%ANT_HOME%" == "" goto endSetAntHome
>       call :environmentVariableError ANT_HOME
>       goto :EOF
> :endSetAntHome
> 
> The "(x86)" in my path causes the FOR in this fragment to barf with "\PC was
> unexpected at this time."

Isn't the general advice that any system that uses batch scripts should
avoid using directories with spaces in -- despite the Windows obsession
with directories that have spaces in the name?

> It is the parentheses that do it...I think they mess up CMD's parsing of the
> for loop.
> 
> "Interestingly", writing "%PATH%" in the script (didn't expect it to work,
> but thought I'd see what it DID), then doing set DEBUG=1 and running gant -v
> crashed the command prompt window!

I seem to recollect that in the dim distant past, I saw this sort of
behaviour.  In some circumstances, executing an exit in a batch file is
interpreted as an exit from CMD.

> I see this is a common issue in the googleverse...but I don't see a common
> solution (I did look) :-(
> 
> Best I can come up with is to go through the parameters one at a time,
> calling dir/x on each element (then you'd have "progra~2"). You'd need to do
> this in a separate batch file, I think...shift only works on %n...
> 
> Alternatively, ask the user to do dir/x on C:\ find the appropriate short
> form for the directory and use that form in their path (did it for me, but
> requires admin rights, so may be impractical).
> 
> Stupid CMD.

gs/CMD/Windows/

:-)

> BOB

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [email protected]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[email protected]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to