What built-in commands does Spring Shell provide, and how do help and history work?

middlenice to knowfreq 22%

answer

help / clear / exit-quit / history / script / stacktrace / version
help <command> shows options + availability
help generated from annotations
history via JLine, persisted to a file
stacktrace shows the last error

basics

~20 s

Spring Shell ships built-in commands like help, clear, exit/quit, history, script, stacktrace, and version. help lists all commands and shows details for one; history records typed commands (recallable with arrow keys and saved to a file).

solid answer

~40 s

Out of the box Spring Shell registers several built-in commands so you do not write them: help (list all commands grouped, or help <command> for its description, options, and availability), clear (clear the screen), exit/quit (leave the shell), history (show or persist the command history), script (run commands from a file), stacktrace (print the last error's stack trace), and version. The help output is generated from your @ShellMethod value/group and @ShellOption help metadata, so documenting annotations pays off automatically. History is provided via the underlying JLine: previously entered commands are navigable with the up/down arrow keys and are persisted to a history file so they survive restarts (configurable, e.g. spring.shell.history.name). Built-ins can be disabled through Spring Shell properties if you need a locked-down console.

Out of the box Spring Shell registers several built-in commands so you do not write them: `help` (list all commands grouped, or `help <command>` for its description, options, and availability), `clear` (clear the screen), `exit`/`quit` (leave the shell), `history` (show or persist the command history), `script` (run commands from a file), `stacktrace` (print the last error's stack trace), and `version`. The `help` output is generated from your `@ShellMethod` value/group and `@ShellOption` help metadata, so documenting annotations pays off automatically. History is provided via the underlying JLine: previously entered commands are navigable with the up/down arrow keys and are persisted to a history file so they survive restarts (configurable, e.g. `spring.shell.history.name`). Built-ins can be disabled through Spring Shell properties if you need a locked-down console.

go deeper

for a junior

Knows help and exit exist as built-ins.

for a middle

Can name the main built-ins and explain help/history behavior and its annotation-driven source.

for a senior

Knows history is JLine-backed and persisted, and that built-ins can be disabled via properties.

for a principal

Considers operator ergonomics, secret leakage via history, and locking down built-ins for restricted consoles.

Built-in commands. Spring Shell auto-registers a set of standard commands so every app has a consistent baseline. Common ones:

help — with no argument, lists all registered commands (grouped, with short descriptions). With an argument, help <command> prints that command's description, its options (names, help text, defaults, whether required), and current availability. This output is derived entirely from your @ShellMethod(value=...), group, and @ShellOption(help=...) metadata — good annotations produce good help for free.
clear — clears the terminal screen.
exit / quit — terminate the interactive session.
history — displays the list of commands you have entered; it can also write them to a file.
script — reads a file and executes each line as a command (batch of commands inside an interactive session).
stacktrace — prints the full stack trace of the most recent exception (interactive shells normally show only a short error message).
version — shows build/version info.

How help stays accurate. Because help is generated from annotations and reflection at registration time, it never drifts from the code. This is a reason to always fill in value and per-option help.

History mechanics. Line editing, arrow-key recall, and history come from JLine, the terminal library Spring Shell builds on. Commands you type are kept in an in-memory ring and persisted to a history file so they survive process restarts; you navigate with Up/Down and can search. The history file name/location is configurable (e.g. spring.shell.history.name), and history can be disabled. Sensitive commands (those containing secrets) are a consideration — history files can leak credentials, so avoid passing secrets as plain options.

Disabling built-ins. Each built-in command group can be turned off via configuration properties (for example to hide exit in an embedded console or remove script in a locked-down environment). This is done through spring.shell.command.*.enabled-style properties.

Gotchas.

stacktrace shows only the last error; run it immediately after a failure.
History persistence can capture secrets typed on the command line — prefer prompting or environment/config for sensitive values.
help reflects availability, so a command may show as unavailable there.

When it matters. These built-ins give operators a familiar, self-documenting console with minimal effort; interviewers use them to check whether you know Spring Shell provides ergonomics (help/history/completion) beyond just command dispatch.

**Built-in commands.** Spring Shell auto-registers a set of standard commands so every app has a consistent baseline. Common ones: - `help` — with no argument, lists all registered commands (grouped, with short descriptions). With an argument, `help <command>` prints that command's description, its options (names, help text, defaults, whether required), and current availability. This output is derived entirely from your `@ShellMethod(value=...)`, `group`, and `@ShellOption(help=...)` metadata — good annotations produce good help for free. - `clear` — clears the terminal screen. - `exit` / `quit` — terminate the interactive session. - `history` — displays the list of commands you have entered; it can also write them to a file. - `script` — reads a file and executes each line as a command (batch of commands inside an interactive session). - `stacktrace` — prints the full stack trace of the most recent exception (interactive shells normally show only a short error message). - `version` — shows build/version info. **How help stays accurate.** Because help is generated from annotations and reflection at registration time, it never drifts from the code. This is a reason to always fill in `value` and per-option `help`. **History mechanics.** Line editing, arrow-key recall, and history come from JLine, the terminal library Spring Shell builds on. Commands you type are kept in an in-memory ring and persisted to a history file so they survive process restarts; you navigate with Up/Down and can search. The history file name/location is configurable (e.g. `spring.shell.history.name`), and history can be disabled. Sensitive commands (those containing secrets) are a consideration — history files can leak credentials, so avoid passing secrets as plain options. **Disabling built-ins.** Each built-in command group can be turned off via configuration properties (for example to hide `exit` in an embedded console or remove `script` in a locked-down environment). This is done through `spring.shell.command.*.enabled`-style properties. **Gotchas.** - `stacktrace` shows only the *last* error; run it immediately after a failure. - History persistence can capture secrets typed on the command line — prefer prompting or environment/config for sensitive values. - `help` reflects availability, so a command may show as unavailable there. **When it matters.** These built-ins give operators a familiar, self-documenting console with minimal effort; interviewers use them to check whether you know Spring Shell provides ergonomics (help/history/completion) beyond just command dispatch.

Where does help get its content from?
From reflection over your annotations: @ShellMethod value/group and @ShellOption help/defaults. Documenting annotations automatically produces accurate help output — it is not maintained separately.
What is a security concern with command history?
History is persisted to a file, so secrets typed as plain command options can leak. Prefer interactive prompts, config, or environment variables for sensitive values, or disable/scrub history.

saying these in an interview costs you the question

Thinking you must implement help/exit/history yourself
Believing help text is written separately and can drift from the code
Ignoring that history persistence can leak secrets typed on the command line

What built-in commands does Spring Shell provide, and how do help and history work?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~2 min

▾common follow-ups2 questions

▾red flags3 flags

§ context

▾related questions3 questions

▾related topics3 topics

answer

go deeper

context