v0.7.0

Explanations follow the script as bash runs it and cite the Bash manual; the web page is redesigned for phones and gets the extension's settings.

New

• Explanations cite the GNU Bash Reference Manual (bash 5.2): a "Bash manual 3.7.2" link in VS Code's hover, a "§3.7.2" link in the panel and on the web page, and the section numbers in the command-line tool's text, Markdown and JSON output.
• The shell state is followed in the order the script runs: set and shopt options, variables (also those set by arithmetic, such as (( i++ )) and let, with their values when known), functions and aliases. A subshell keeps its changes, a function's body counts where it is called, and an option set only in a branch "may" be on. Before, anything earlier in the text counted, even in a subshell or a function that never ran.
• New notes on which command really runs: a function that replaces a builtin or a program (and how to reach the other with builtin or command), enable -n, hash -p, special builtins in POSIX mode, names that may come from a sourced file, and functions defined in a subshell or removed with unset -f.
• New notes on subshells and other shells: cd, set -e or exit in a subshell only change the subshell, and $$ there is still the script's PID. Code run by bash -c, sudo, su -c, ssh or docker exec gets a pitfall when it uses a variable or function of the script that the new shell does not have, with the fix (export, export -f, or passing declare -f).
• New set -e notes: x=$(cmd) stops the script on failure but local x=$(cmd) does not; a pipeline without pipefail hides a failure; a function ending in test && cmd returns the test's failure; and the places where bash ignores set -e.
• Idiom notes for getopts, getopt with eval set --, while [ $# -gt 0 ], read -d '', find -print0 / xargs -0, mapfile, read -p, and while read … done < file, whose redirection is now explained on the loop's first line.
• Syntax colouring from the same tree as the explanations. The web page uses it always, in the explanation panel's colours, so a word has the same colour in the editor and in the explanation; VS Code and the Language Server send it as semantic tokens with the new setting bashExplainer.highlight.enabled (off by default). Heredocs end where bash ends them, so the code after one is no longer coloured as a string.
• The command-line tool reads a settings file with the keys of VS Code's settings.json (--config, $BASH_EXPLAINER_CONFIG or ~/.config/bash-explainer/settings.json), with --set key=value, --no-config and --print-config. The Language Server takes every setting that applies to it, and reads the same file. Before, only the language, the shell and the examples could be set.
• The web page has a settings sheet (the gear) with the extension's settings that apply there, including notes, warnings, kinds of examples and your own commands. Settings can be exported as a settings.json file for VS Code or the command-line tool, and imported back; "Clear stored data" forgets everything the page keeps in the browser.
• On a touch screen, the web page has a read mode: taps move the cursor without opening the keyboard (a tip points to it the first time). A new "Wrap long lines" setting avoids sideways scrolling, and the Problems list can be resized and folded.

Changed

• Your own commands: bashExplainer.customCommands now takes options as a list (each with its names) and operands as a list (with "repeat"), plus an optional style and subcommands. The old shape still works but is deprecated, and a later release drops it. A custom command now follows only what the setting says: one named head no longer reads -5 as -n 5.
• Markdown code blocks tagged sh or shell are read as bash unless they start with a shebang, so they no longer get POSIX sh warnings. To check a block as POSIX sh, start it with #!/bin/sh.
• The web page is redesigned: it fits the window, with the editor and the explanation in panes and a draggable divider between them. A compact top bar replaces the toolbar and footer; a menu slides in from the left and the settings from the right (also with swipes), and slide out again when closed with ×, Esc or a tap beside them. The explanation panel's header moved to the page: "Collapse all", "Quick reference" and "Copy as Markdown" are buttons in the top bar, and the shell and yq are in the menu (and the top bar on a wide window). The file kind is a compact button with a list in the top bar. On a phone the top bar shows the logo and the name "Bash Explainer", and the file kind, the copy and the link are in the menu; on a touch screen the quick reference no longer opens the on-screen keyboard (VS Code's panel is unchanged).
• The web page remembers the language, shell and yq you chose. Before, they were reset on each visit.
• In the panel, the current line stays at the top while the explanation scrolls. Clicking a row of an if or a loop no longer moves the cursor to its last line, and clicking a row scrolls a long line sideways to that part.

Fixed

• Explanations match bash in more places: ~ after = and : in assignments and assignment-like arguments, nullglob / failglob / GLOBIGNORE, set -f on some paths, ambiguous redirection targets (> *.log), no globbing in x=*.txt, no word splitting in <<< $x or ${s:$i}, unquoted patterns in case and [[ ]], a=(x)y, and $_.
• Words a command passes to another command are read as that command reads them: ssh host ls -l, flock f -n true, bash -ex script.sh -x, sh -s -- --prefix x, env -S, sudo -i cmd and watch cmd. Options written with quotes or expansions (ls "-l", ls -$opts) are options; abbreviated long options are read when the tool accepts them, and ambiguous ones are shown as such.
• Options of specific tools are read as the tools read them, among them git's global options, ip's abbreviations, ps, kill, trap, declare, pushd, exit -1, command -v, timeout, locate -r, ar and /bin/echo or other builtins run by path.
• Editing an example's input in the VS Code panel updates the output again when the command has a variable (such as "$f"). The xargs -0 -I{} example runs once per name, and jq 'def g(x' no longer stops the explanation.
• A Dockerfile RUN warns about a pipe without pipefail unless set -o pipefail runs before the pipe; before, the word pipefail anywhere in the RUN, even in a comment, silenced it.
• On the web page, the Problems list shows code as code instead of raw backticks.

All changes