Wanted: --quit runtime option

[Zach Beane]

I run SBCL from the command-line quite a bit, and I also often want to do some stuff and immediately quit. Right now, that means adding --eval '(sb-ext:quit)'. It would be a tiny bit of niceness if --quit was a synonym for that eval form.

[Josh Elsasser (josh-elsasser)]

It would also be nice if --quit would simply set a flag to quit when command-line processing is finished, rather than simply expand into --eval '(quit)'. This would allow for situations such as sbcl --quit --eval '(something-which-uses-posix-argv)' foo bar baz

[David Lichteblau (david-lichteblau)]

* Josh Elsasser
> It would also be nice if --quit would simply set a flag to quit when command-line
> processing is finished, rather than simply expand into --eval '(quit)'. This would
> allow for situations such as sbcl --quit --eval '(something-which-uses-posix-argv)' foo bar baz

On the other hand, Zach's original description of a --quit option is closer to the behaviour of --eval and --load, and therefore perhaps less surprising than the more fancy mechanism.

My current thinking is that I'll implement the original description, but I do not have a particularly strong opinion either way.

Zach (or others): Do you prefer one over the other?

[Zach Beane (xach)]

David Lichteblau <email address hidden> writes:

> On the other hand, Zach's original description of a --quit option is
> closer to the behaviour of --eval and --load, and therefore perhaps less
> surprising than the more fancy mechanism.
>
> My current thinking is that I'll implement the original description, but
> I do not have a particularly strong opinion either way.
>
> Zach (or others): Do you prefer one over the other?

I don't have a preference. I know some other Lisps have similar behavior
under the guise of something like --batch, which means approximately
"never enter an interactive mode", whether it's the debugger or the main
repl.

[Attila Lendvai (attila-lendvai)]

the closest lispworks has is -build, which is --load and then quit:
http://www.lispworks.com/documentation/lw60/LW/html/lw-484.htm#pgfId-891723

allegro has -kill, which is --eval (quit), and also --batch:
http://ai.eecs.umich.edu/people/dreeves/misc/lispdoc/startup.htm#starting-acl-1
-batch Run in batch mode: input comes from standard input, exit when an EOF is read. Exit on any error (but print a backtrace to *error-output* if -backtrace-on-error also specified).

my 0.02: if i saw a --quit argument then i'd have no clue what it does after 20 years spent programming, and reading in the documentation that it's a --eval (quit) would surprise me. bottom line: it's just pretty much noise, an extra indirection that doesn't give much in return.

now, if it's like --batch or something that does many other things to accommodate for a frequent use-case... than that's a different story.

see also: https://bugs.launchpad.net/sbcl/+bug/586434

[David Lichteblau (david-lichteblau)]

Okay, so I'm planning to commit this:

1. --quit works as suggested by Josh (i.e. delays the quit to the end of toplevel option processing).

2. --noninteractive will be the combination of --quit and --disable-debugger

3. Anyone who really wants exactly --eval '(quit)' without a delay needs to write that explicitly.

Naming rationale:

"quit" is nice and short, hence hard to beat as an option name.
"noninteractive" seems a lot clearer than the alternatives (like "batch", which could confused easily with "script").

[Attila Lendvai (attila-lendvai)]

another 0.02: i'd make that "--non-interactive" (the version with dash also wins on google-fight 3 to 1)