This has me totally baffled.
Specs: Linux Mint 18.3, Java 11, Groovy 2.5.9.
It may be of interest that these files are on an NTFS-formatted partition.
I make a simple Groovy script file with a simple #Grab:
package test;
#Grab(group='org.apache.commons', module='commons-lang3', version='3.7')
println "bye"
... fails:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/media/chris/W10 D drive/My Documents/software projects/EclipseWorkspace/GroovyExp2020-03-08/src/test/testscript.groovy: 5: unexpected token: println # line 5, column 1.
println "bye"
^
1 error
If I comment out the #Grab line it runs OK.
If I make the script like this:
package test
def bosh = "jellow world"
bosh = "bash"
#Grab(group='org.apache.commons', module='commons-lang3', version='3.7')
bosh = "bish"
... the complaint, flagged for the last line there, changes to "Groovy:The current scope already contains a variable of the name bosh" (!).
If I put a semicolon at the end of the Grab line:
package test;
#Grab(group='org.apache.commons', module='commons-lang3', version='3.7');
println "bye"
... the complaint becomes "Unexpected token:;"
So far so bafflingly inexplicable. Even stranger is the fact, however, that some of my existing scripts still work OK: I can insert a #Grab line like the above, with no complaints about "unexpected token".
This is not Eclipse-generated nonsense: I get the same issues at the Linux CLI.
You can't just stick annotations anywhere in groovy (or Java)
You need to annotate a class, method or field
In your examples, you're annotating a variable assignment (which won't work), and a method call (which also won't work)
Move the annotation to the top of the file, or to a class definition
Related
I'm facing the following error:
&*chdir('/home/account')
Failed to change the working directory to '/home/account': Default constructor for 'IO::Path' only takes named arguments
What do I need to change to overcome this error?
(I am using perl6 version 2013.12 Ubuntu 14.04)
2013.12 is 4.5 years old. I would not recommend learning Perl 6 with that version. Please try to get a more recent version: the documentation for it will be more up to date, and it will be one, if not 2 orders of magnitude faster.
Also, why not use chdir instead of &*chdir? The latter being something that is relic from ancient times, afaik. If you just chdir, you get:
$ perl6 -e 'chdir("/home/account")'
Failed to change the working directory to '/home/account': does not exist
Which is definitely already much more understandable.
Secondly, if a chdir fails, it returns a Failure. When a Failure is sunk (aka being called in "void" context in Perl 5 terms), it will throw the Exception it contains. Which is what you just saw.
chdir returns an IO::Path object if successful, which is True in a Boolean context such as an if or a ternary:
$ perl6 -e 'say chdir("/home/account") ?? "Yeah!" !! "Alas"'
Alas
But in most cases where you want to do something inside a directory, you will want to use indir( $path, { code to execute } ). That will ensure that no code will be executed in that directory except for the code given as the second parameter.
There are few scripts getting called in my main script, one of which when executed separately executes well, but when executed from the main, gives an error as below,
((: s<=: syntax error: operand expected (error token is "=")
s is my variable in my for loop as,
for((s=1;s<=$someVar;s++))
I'm exporting this someVar from my main script, so that this script can use that var, however its already able to get the value of that var.
someVar is not set with a value.
I'm able to reproduce it with this:
for((s=1;s<=$someVar;s++)); do
:
done
Error output:
... 3: ((: s<=: syntax error: operand expected (error token is "=")
P.S. You're probably running Bash 3.x.
I've been able to add a Linux machine as build agent in TeamCity without too much hassle, but it's having some trouble running my Perl test suite. When I add this as a build step:
prove -j4 --formatter TAP::Formatter::TeamCity
I get the following error :
Missing '...' at end of YAMLish at /usr/local/lib/perl5/site_perl/5.18.0/TAP/Parser /YAMLish/Reader.pm line 49, line 2.
Process exited with code 25
Step Run test scripts (Command Line) failed
I actually get that whether I pass a --formatter value or not. When I run this from the local command line of the same machine, it runs just fine. That area in Reader.pm looks like this:
# The terminator is mandatory otherwise we'd consume a line from the
# iterator that doesn't belong to us. If we want to remove this
# restriction we'll have to implement look-ahead in the iterators.
# Which might not be a bad idea.
my $dots = $self->_peek;
die "Missing '...' at end of YAMLish" #Line 49
unless defined $dots
and $dots =~ $IS_END_YAML;
I tried changing that die to a warn and sure enough it started ingesting all the console output and it of course choked before too long.
uname -r on the Linux box yields 3.5.0-45-generic #68-precise1-Ubuntu.
Anyone know any ways around this?
This is sort of obscure, but I can't figure it out.
I have a program that uses Groovy's CliBuilder to parse command line options. Here's a simplified version of the code:
args.each { println it }
def cli = new CliBuilder(usage: '...usage...')
cli.n(args: 1, 'The name')
def options = cli.parse(args)
println ":" + options.n
I run the program with:
groovy test.groovy -n name
Using Groovy 2.1.7, I get the expected response:
-n
name
:name
Using Groovy 2.2.2, I get something strange:
?
name
:false
This only happens when using -n as a command-line option. I don't know if it conflicts with Groovy's own -n option or not. It doesn't seem to in 2.1.7. Using -n also breaks any subsequent options passed on the same command line.
Is this a bug? Is the workaround just to avoid -n?
I have a groovy file named test.groovy and have a single line of coding in it :
println args[0];
when I run this program like this groovy test ants, output is ants.
But when I run the program with the argument ants( then I'm getting error like this :
bash: syntax error near unexpected token (
1)If I escape the character ( then I'm getting the output as ants(. But why ( is needed to be escaped?
And when I run the program with the argument ant's, then clicking enter would make my terminal look like this :
>
>
>
2)And I terminate the program only using ctrl+c. What actually happens in this case? Why my terminal look like this?
3)After seeing these, what are the rules and condition that are to be followed in Groovy with accordance with Command-line arguments and the same holds for Java?
Thanks in advance.
You need to escape it as ( has a meaning in the bash shell which you are using.
The same goes for '
Try other commands:
ls (
Or
ls '
You'll get the same effect
Another option (other than escaping) is to put your arguments inside quote chars like so:
groovy test 'ants('