Wanted: --quit runtime option
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| SBCL |
Undecided
|
David Lichteblau |
Bug Description
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.
Changed in sbcl: | |
assignee: | nobody → David Lichteblau (david-lichteblau) |
status: | New → In Progress |
Josh Elsasser (josh-elsasser) wrote : | #1 |
* 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-
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?
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) wrote : | #4 |
the closest lispworks has is -build, which is --load and then quit:
http://
allegro has -kill, which is --eval (quit), and also --batch:
http://
-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.
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) wrote : | #6 |
another 0.02: i'd make that "--non-interactive" (the version with dash also wins on google-fight 3 to 1)
Changed in sbcl: | |
status: | In Progress → Fix Committed |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
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