2013-06-13 18 views
12

To nie działa:Groovy: Co jest nie tak z tym programem "Hello World"?

$ groovy -e 'println "Hello, world!"' 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: 
script_from_command_line: 1: unexpected char: 0xFFFF @ line 1, column 23. 
    println "Hello, world! 
         ^

1 error 

Jednak oddanie przestrzeni pomiędzy ostatnim podwójnie i apostrofu działa ...

$ # groovy -e 'println "Hello, world!"' 
$ groovy -e 'println "Hello, world!" ' 
Hello, world! 

... chociaż bash wydaje się być w stanie poprawnie obsługiwać spływu "' parę (czyli bez jakiejkolwiek przestrzeni pośredniej) w następujący sposób:

również parenthesizing z println argumentem działa dobrze:

$ groovy -e 'println ("Hello, world!")' 
Hello, world! 

Teraz chciałbym wiedzieć, dlaczego to pierwszy przypadek nie działa.

Używam:

  • bash, wersja 4.2.45 "(1) -release (x86_64-pc-linux-gnu)"
  • Groovy, wersja 2.1.3
+2

To nie jest problem _bash_, jest to groźny problem. (_zsh_, _csh_ i _dash_ wszystkie wykazują zachowanie zapisu). – DaoWen

+0

Dziwne. 0xFFFF to [nie ma nawet zdefiniowanego punktu kodowego w Unicode] (http://www.fileformat.info/info/unicode/char/ffff/index.htm). –

+0

@RayToal - "0xFFFF" to -1 lub EOF (koniec pliku). – DaoWen

Odpowiedz

-2

To działa poprawnie na OSX. Myślę, że ten błąd ma związek z niewłaściwym rozwiązaniem. Poniższe działa na Linux:

groovy -e 'println "Hello, world!";' 
0

widzę wyjątek działa w wersji 2.1.3 i Java 6:

C:\Users\mwest>groovy -e 'println "Hello, world!"' 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: 
script_from_command_line: 1: expecting ''', found '<EOF>' @ line 1, column 9. 
    'println 

ciekawe odwrócenie cytaty działa

C:\Users\mwest>groovy -e "println 'Hello, world!'" 
Hello, world! 
3

Jak BDKosher już wspomniano, jest to błąd z interfejsu API Apache Commons. Groovy chce zaktualizować do wersji 1.3, ale ludzie CLI poświęcają swój czas tej wersji i zawiera ona niezgodności.

I jak już napisałem w powyższym komentarzu już 0xFFFF jest używane przez antlr do pokazania końca pliku, nie musi to być poprawna postać Unicode. Sformułowanie zostało skrytykowane z tego powodu, ale sformułowanie pochodzi z generatora parsera antlr, a nie od nas.