|
Is this just another version of
if it is you can check it easily by giving the script any extension like .groovy
Looks like it is then. If I have scriptNameAlt.groovy as a copy then it runs fine with a relative path.
I will mark this as a replica. This is a duplicate and so being closed.
The script:
#! /usr/bin/env groovy
// -*- mode:groovy encoding:UTF-8 -*-
println ( 'Hello World' )
has the execute bit set so can be executed as a command (on a proper operating system anyway This script executes fine using the command lines: GROOVY_569 ./GROOVY_569 assuming you are in the directory in which the script is. Even: /home/users/russel/Progs/OddsByLanguage/Groovy/GROOVY_569 seems to work fine. However: ../Groovy/GROOVY_569 generates the original error: Caught: java.lang.NoClassDefFoundError: /
at ..class$(GROOVY_569)
at ..get$class$$(GROOVY_569)
at ..<clinit>(GROOVY_569)
I am therefore reopening this bug. Works for me from Subversion r10562. However this would give a fix relaease of 1.6.0. I guess more commit magic is needed to get this into 1.5.2.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.
|-- bin
| `-- scriptName
\`-- location
and if scriptName is execute from the directory bin or by absolute path then it works fine. If called using ../bin/scriptName from location then:
Caught: java.lang.NoClassDefFoundError: /
at ..class$(scriptName)
at ..<clinit>(scriptName)
I think this should be considered a blocker. I will raise the priority on this. If I have misunderstood or got something wrong, the change can be reverted.