The `js' program is the JavaScript interpreter command. It can be used to execute JavaScript and JavaScript byte-code files. The progam can also be used to compile JavaScript files into the byte-code files.
The js
program is invoked as:
js
option... file [argument...]
The js
program processes the command line options and
when the first non-option argument, or the option `--file', is
encountered, it is assumed to contain JavaScript or byte-code that
should be evaluated. The interpreter will pass all remaining arguments
to the script throught the `ARGS' array. The items in the array
are strings containing the arguments argument.... The first
item of the array is always the name of the script file.
The options can be one or more of the following command line options:
-a
--annotate-assembler
-c
--compile
-d type
--dispatch=type
switch-basic
switch
jumps
-e code
--eval=code
$ js --eval='System.print ("Hello, world!\n");' -| Hello, world!
-E
--events
$ js -E -c test.js [js: garbage collect] [js: garbage collect] [js: garbage collect] [js: garbage collect]
-f
--file
ARGS
array. The first item of the
array will be the name of the script, i.e. the argument that follows the
option `--file'.
$ cat hello.js -| var i; -| for (i = 0; i < ARGS.length; i++) -| System.print (i, ": ", ARGS[i], "\n"); $ js --file hello.js a b c d -| 0: hello.js -| 1: a -| 2: b -| 3: c -| 4: dThe option can also be used with the option `--load' to indicate the last file to load. Also in that case, the remaining arguments will be passed to the script through the
ARGS
array.
-g
--debug
-h
--help
-l
--load
--load
, multiple files can be loaded the to the
interpreter. The loading can be stopped with option --file
that
specifies the last file to load.
For example, if we have files `a.js':
function do_a () { System.print ("do_a()\n"); }`b.js':
function do_b () { System.print ("do_b()\n"); }and `main.js':
do_a (); do_b ();the whole application can be run as:
$ js --load a.js b.js --file main.js arguments... -| do_a() -| do_b()
-N
--no-compiler
-O [level]
--optimize[=level]
0
1
2
-r option
--secure=option
file
system
-s size
--stack-size=size
-S
--assembler
-t
--stacktrace
function recursive (level) { if (level <= 0) error ("recursion limit exceeded"); else recursive (level - 1); } recursive (5);If the program is executed without the `--stacktrace' option, the following result is shown:
$ js hello.js js: evaluation of file `hello.js' failed: hello.js:6: recursion limit exceededWith the `--stacktrace' option, the `js' program will print the following error message:
$ js --stacktrace hello.js -| VM: error: hello.js:6: recursion limit exceeded -| VM: stacktrace: stacksize=2048, used=44 -| #0 recursive(): null 1 "recursion limit exceeded" -| #1 recursive(): null 1 0 -| #2 recursive(): null 1 1 -| #3 recursive(): null 1 2 -| #4 recursive(): null 1 3 -| #5 recursive(): null 1 4 -| #6 .global(): null 1 5 -| js: evaluation of file `hello.js' failed: -| hello.js:6: recursion limit exceeded
-v
--verbose
-V
--version
js
program.
-W option
--compiler-option=option
no-
', the specified option will be turn off. The following
option specifications are currently implemented:
all
pedantic
runtime
shadow
undefined
unused-argument
unused-variable
with-clobber
missing-semicolon
strict-ecma
deprecated
-x
--executable
$ cat hello.js -| System.stdout.writeln ("Hello, world!"); $ js -cx hello.js $ ./hello.jsc -| Hello, world!
The compilation of JavaScript code is carried out with the following command:
js
[options] -c
file...
where file is a JavaScript source file to compile and options specify additional compiler options.
In the simplest form, the compilation goes as follows:
$ js -c hello.js
This example compiles file `hello.js' to byte-code file `hello.jsc' with the default compiler options.
It is nice to get as many error messages as possible at the compilation
time. However, sometimes some error messages are false and it is
annoying to see them every time you compile your project. The option
--compiler-option
can be used to adjust the level of warning
messages the compiler generates.
Normally we want to get all possible compiler time warnings. They can
be enable with the -Wall
option. To set the warnings
individually, the following options can be given for the
--compiler-option
option. The option names can be prefixed with
string `no-' to turn them off instead of setting them. For
example, let's assume that we want to get as much warnings as possible,
but we do not care about unused function arguments:
$ js -Wall -Wno-unused-arguments -c hello.js
In this example, we turn on all warnings `-Wall', but we turn off warnings about unused arguments `-Wno-unused-arguments'.
The js
program knows the following warning options:
shadow
function foo (a, b) { var a = 1; return a + b; }the following warning is generated:
$ js -Wshadow -c test.js -| test.js:3: warning: declaration of `a' shadows a parameter
unused-argument
function foo (a, b) { return a + 5; }the following warning is generated:
$ js -Wunused-argument -c test.js -| test.js:1: warning: unused argument `b'
unused-variable
function foo (a, b) { var c; return a + b; }the following warning is generated:
$ js -Wunused-variable -c test.js -| test.js:3: warning: unused variable `c'
with-clobber
function foo (PI) { with (Math) System.print ("PI=", PI, "\n"); }the following warning is generated:
$ js -Wwith-clobber -c test.js -| test.js:4: warning: the with-lookup of symbol `PI' is -| clobbered by the argument definition
missing-semicolon
function foo () { return 1 } foo ()the following warnings are generated:
$ js -Wmissing-semicolon -c test.js test.js:3: warning: missing semicolon test.js:6: warning: missing semicolon
strict-ecma
function foo () { System.stdout.writeln ("Hello, world! "); }the following warning is generated:
$ js -Wstrict-ecma -c test.js test.js:3: warning: ECMAScript don't allow line terminators in string constants
deprecated
function foo () { for (var i in arguments) System.stdout.writeln (i); }the following warning is generated:
$ js -Wdeprecated -c test.js test.js:1: warning: the `arguments' property of Function instance is deprecated
Besides the compiler time checks, the virtual machine can also perform some checks at the runtime. These checks can be set and unset with the `-Wruntime' option.
The following runtime warnings are supported:
undefined
foo = an_undefined_variable;the following warning is generated:
$ js test.js -| VM: warning: using undefined global `an_undefined_variable'
As a default, the JavaScript compiler do not include symbolic debugging
information to the generated byte-code files. The debugging information
can be generated by giving the compiler -g
option. The debugging
information is also generated for the internal byte-code files that are
created when the interpreter evaluates plain JavaScript source code.
In the current implementation, the debugging information contains only the names of the source files, and mappings from the virtual machine program counter offsets to the source file locations. In the future, it will contain information about local variables and function arguments, so that the symbolic debugger can print their values.
The presence of the debugging information shows in the error messages the interpreter shows. For example, let's consider the following JavaScript source code file `test.js':
function foo (a) { a += 1; if (a > 50) error ("a overflow"); return 1; } foo (50);
When this file is compiled to the byte-code without debugging information, the following error message is raised:
$ js -c test.js $ js test.jsc -| js: evaluation of file `test.jsc' failed: -| a overflow
If we recompile the file with the debugging information, we will get a more precise error message from the interpreter:
$ js -g -c test.js $ js test.jsc -| js: evaluation of file `test.js' failed: -| test.js:5: a overflow
Now we see the exact source code location where the error occurred.
The debugging information can be removed from the byte-code files after
the compilation with the jsdas
program.
$ jsdas --strip test.jsc test.jsc: jsdas: removing section 3 $ js test.jsc js: evaluation of file `test.jsc' failed: a overflow
The JavaScript compiler can generate assembler listings from the
JavaScript source files. The assembler listings are generated just
before the resulting byte-code data would be generated. So the resulting
assembler listing is exactly the same that will be in the resulting
byte-code data. The assembler listing is generated with the
--assembler
option. For example, if we have a source file
`hello.js' with the following contents:
function hello () { System.stdout.writeln ("Hello, world!"); return true; } hello ();
it can be compiled to assembler with command
$ js -S hello.js
The command will save the assembler listing in file `hello.jas':
hello: load_arg 1 add_2_i min_args 2 const "Hello, world!" const_i1 load_global System load_property stdout call_method writeln pop_n 4 const_true return .global: const_i0 const_null jsr hello apop 2
The option --annotate-assembler
can be used with the
--assembler
option. It mixes the original source code to the
generated assembler listing. In this format, it is easy to see how
different JavaScript constructs are compiled in the assembler. Our
example file can be compiled to the annotated assembler with the
following command:
$ js -a -S hello.js
The result listing is saved to file `hello.jas':
; -*- asm -*- ; function hello () hello: ; { load_arg 1 add_2_i min_args 2 ; System.stdout.writeln ("Hello, world!"); const "Hello, world!" const_i1 load_global System load_property stdout call_method writeln pop_n 4 ; return true; const_true return ; } ; ; hello (); .global: const_i0 const_null jsr hello apop 2
Go to the first, previous, next, last section, table of contents.