Batch processing returns with success (0), even when there is an error.

[c-kloukinas]

Trying to use abcl in github actions (to test porting coalton to it).
Whenever it breaks, it still exits with a 0 (success), instead of with a 1 (error), that other lisps exit with.

Example:

cat > bug.lisp << EOF
(print x)
EOF
abcl --batch --load bug.lisp < /dev/null
echo $?
# returns 0

Other lisps that I've tried return 1 or at least a non-zero value:

sbcl --script bug.lisp ; echo $?
# 1
clasp --script bug.lisp ; echo $?
# 1
ecl --shell bug.lisp ; echo $?
# 1
ccl --batch --load bug.lisp ; echo $?
# 255
alisp --batch -L bug.lisp ; echo $?
# 255

Note: Returning a stack trace in such cases would be helpful for debugging.

Shouldn't --batch imply no REPL by the way?
Or at least, have an option to turn the REPL off?

[easye]

ABCL should signal the appropriate non-zero status when EXTENSIONS:QUIT is invoked with an a keyword :status integer argument. I'll have to look at all the cases where this happens later, but it has largely exhibited correct in the past from what I recall.

You should check how the script invoking the JVM handles the error. Maybe you need to change that to an explicit exec()?

[c-kloukinas]

The examples I provided were all command-line examples (that I've tried at the bash prompt).

Calling extensions:quit works, when the previous code works. But if there's a bug in the previous code then the quit never gets executed.

In the script I'm using, abcl is executed midway - my understanding is that using an explicit exec abcl --batch --load bug.lisp < /dev/null there would not execute any of the remaining parts of the script on success?

[c-kloukinas]

You should check how the script invoking the JVM handles the error. Maybe you need to change that to an explicit exec()?

I had probably misunderstood you here. Here's a direct call of the jvm (same results):

java -server -Xrs -cp  /usr/local/src/abcl/dist/abcl.jar org.armedbear.lisp.Main --batch --load bug.lisp < /dev/null
echo $?
# 0

In src/org/armedbear/lisp/Main.java, there is indeed a catch (ProcessingTerminated e) System.exit(e.getStatus());

So I guess that when the debugger is launched and it's not supplied with any input at all (since here it's running in a non-interactive manner), then the debugger terminates normally, instead of throwing an exception.

Indeed, in src/org/armedbear/lisp/debug.lisp, function internal-debug checks to see if tpl::repl is fboundp and it simply does a (quit) when it's not, instead of doing a (quit :status 1).
Same in invoke-debugger.

Interestingly, changing that code to print a message and then do a (quit :status 1), had no difference in behaviour at all!!! Didn't even print my message. A bit puzzled.
This, however, did show my message & returned 1:

java -server -Xrs -cp  /usr/local/src/abcl-chris/dist/abcl.jar org.armedbear.lisp.Main  --noinform --eval "(fmakunbound 'tpl::repl)" --load bug.lisp < /dev/null ;
echo $?

So... I've tried to extend the src/org/armedbear/lisp/Interpreter.java code that processes --batch (preprocessCommandLineArguments) to do an (fmakunbound 'tpl::repl) but that didn't do anything.

Therefore, I moved this code at the start of postprocessCommandLineArguments. No behaviour change either.

So, I've tried simply checking for *batch-mode* inside internal-debug & invoke-debugger instead - success! (unless I've missed something really obvious...)

So, now you know why this PR came to be and what it's trying to do.

Not sure why there's a REPL in batch mode.
Also not sure if debugger should simply quit when there's no REPL (as it does now) or it should quit with 1.

[c-kloukinas]

Interestingly, an error in an --eval returns 2, even when not in batch mode:

$ abcl --noinform --eval '(load "not-there")' ; echo $?
Caught FILE-ERROR while processing --eval option "(load "not-there")":
  File not found: /usr/local/src/abcl-chris/not-there
2
$

So I guess instead of --load file-foo.lisp in batch mode, one can --eval '(load "file-foo")' instead.