@eslint-sh/eslint-plugin 0.5.0 → 0.7.0

package/docs/rules/require-network-wrapper.md

@@ -0,0 +1,171 @@
+# `sh/require-network-wrapper`
+
+Require network commands (`curl`, `wget`, `ssh`, `git fetch`, …) to be run through your project's
+configured wrapper, such as a retry or audit helper.
+
+| Configs | Fixable     | Languages |
+| ------- | ----------- | --------- |
+| `agent-authored` (inert until a wrapper is configured) | not fixable | `sh/sh` |
+
+## Rule details
+
+Network calls fail in ways local commands don't: timeouts, rate limits, flaky DNS. Many projects
+route every network call through one wrapper that retries, logs, or proxies it. This rule checks
+that every network command a script runs goes through that wrapper.
+
+**The wrapper has no default.** Which wrapper your project uses is your policy, and a generic
+linter must not invent it. With no wrapper configured, the rule is inert: it reports nothing.
+
+The rule checks every command in the file: top level, in functions, in pipelines, in
+conditionals, and inside command substitutions (`$(…)`). A network command is reported (message
+`unwrappedCommand`, on the whole command) unless the configured wrapper runs it. It is wrapped
+when the wrapper encloses it, directly (`retry curl x`) or through transparent wrappers such as
+`sudo`, `env`, or `nohup` (`retry sudo curl x`, `sudo retry curl x`). `sudo curl x` is not
+wrapped, and neither is the `curl` in `retry echo "$(curl x)"`: the command substitution is its
+own command. See [Wrapper rules](../wrapper-rules.md) for the full matching rules.
+
+A command run by path is matched by its basename, so `/usr/bin/curl x` and `./bin/curl x` report
+as `curl`. A wrapper run by path is the wrapper it names: `/usr/local/bin/retry curl x` is wrapped.
+
+`git` counts only for its network subcommands, `fetch`, `clone`, `pull`, and `push`. git's global
+options before the subcommand are skipped, so `git -C dir fetch` is reported as `git fetch`, and
+`git status` is not reported.
+
+Invocations that only act locally are not reported: `curl --version`, `curl --help`,
+`curl --help all`, `wget --version` and `wget --help`, and their short forms `-V` and `-h`
+(`curl -h all`). The argument list must be exactly that, so `curl --version https://example.com`
+still reports. `git clone` is not reported when its source is a literal local path (`./x`, `../x`,
+`/x`) or a `file://` URL, after any of git clone's own options (`git clone --depth 1 ./x`). Only
+the source decides: a dynamic destination (`git clone ./x "$dest"`) does not matter, but a dynamic
+source (`git clone "$src"`), a remote URL, and a clone option the rule does not know leave the
+clone reported. So do `--recurse-submodules`, `--recursive` and `--remote-submodules` (a local
+repository's `.gitmodules` can point at a remote URL, which those options fetch) and
+`--bundle-uri` (it fetches from its URL, `--bundle-uri=URL` or `--bundle-uri URL`, whatever the
+source is). `--no-recurse-submodules` and an attached or separate option value such as `-j4` or
+`-j 4` do not change that the source is local. Options are read wherever they appear before a literal `--`, so
+`git clone ./x --recurse-submodules` and `git clone ./x d --bundle-uri URL` report too, while
+`git clone ./x -- --recurse-submodules` (everything after `--` is an operand) does not. A rule pack binds
+the same kind of exemptions in [`createWrapperRule`](../wrapper-rules.md) with
+`localInvocations`; the factory itself names no command.
+
+A call to a function the file defines is not reported, even when the function is defined after the
+call, because it runs the function and not the network client. A real invocation inside the
+function (`command curl x`) is reported.
+
+The rule never guesses. A dynamic command word (`"$client" x`), an option your wrapper does not
+declare (`retry -n 3 curl x` when `retry` is configured as a plain name), and a dynamic git
+subcommand (`git "$op"`) leave the command unknown, and nothing is reported. Command strings run
+by another shell (`bash -c 'curl x'`) are not checked.
+
+It does not depend on `languageOptions`.
+
+## Options
+
+- `wrapper` (`string` or `WrapperSpec` object, no default): the wrapper network commands must be
+  run through. When it is unset, the rule uses `settings.sh.networkWrapper` (below); with
+  neither, the rule reports nothing. A string names a wrapper that takes no options
+  (or one of the default transparent wrappers, such as `timeout`, whose options are known). An
+  object declares the wrapper's options so the command after them is found:
+  `{ names: ['retry'], argFlags: ['-n'] }` makes `retry -n 3 curl x` wrapped. Its fields are
+  `names` (required; any of them counts as the wrapper), `noArgFlags`, `argFlags`,
+  `stopsChainFlags`, `unresolvableFlags`, `positionalOperandsBeforeCommand`, and
+  `assignmentOperands`, as in `sh-ast/analyze`'s `WrapperSpec`.
+- `commands` (`string[]`, default `["curl", "wget", "nc", "ssh", "scp", "rsync", "git"]`): the
+  network commands. Setting it replaces the default list. `git` keeps its subcommand restriction
+  wherever it is listed.
+- `alsoTreatAsNetwork` (`string[]`, default `[]`): more commands to check, added to `commands` (or
+  to its default).
+
+```js
+// eslint.config.js
+{
+  rules: {
+    'sh/require-network-wrapper': ['error', { wrapper: 'retry', alsoTreatAsNetwork: ['aws'] }],
+  },
+}
+```
+
+### Declaring the wrapper once: `settings.sh.networkWrapper`
+
+`sh/no-undeclared-commands` and `sh/no-unused-declarations` also need to know about your wrapper:
+in `with-retry curl x` the script runs `curl`, and only a rule that looks through `with-retry` sees
+that. ESLint doesn't let one rule read another rule's options, so a wrapper set only as this rule's
+`wrapper` option is invisible to them, and an undeclared `curl` behind it goes unreported.
+
+Set the wrapper in shared settings instead, and all three rules read it:
+
+```js
+// eslint.config.js
+{
+  settings: { sh: { declarationConvention: commentPragma, networkWrapper: 'with-retry' } },
+  rules: { 'sh/require-network-wrapper': 'error' }, // or extend sh.configs['agent-authored']
+}
+```
+
+`networkWrapper` takes the same values as the `wrapper` option, a name or a `WrapperSpec` object,
+and the declaration rules follow a spec's options too (`with-retry -n 3 curl`). This rule's
+`wrapper` option, when set, takes precedence for this rule only. A malformed value stops linting
+with an error starting `Invalid settings.sh.networkWrapper:`.
+
+The setting names your **network** wrapper, a policy. Other wrappers that run a command, such as
+a `with-lock` helper, aren't network policy: list those in the declaration rules'
+`transparentWrappers` option.
+
+## Examples
+
+### Incorrect
+
+With `{ wrapper: 'retry' }`:
+
+<!-- example: {"options": {"wrapper": "retry"}, "findings": 6} -->
+
+```sh
+curl -fsSL https://example.com/install.sh   # curl is not wrapped
+retry echo start; curl x                    # retry wraps echo, not curl
+sudo curl x                                 # sudo is not the configured wrapper
+git -C repo fetch                           # reported as `git fetch`
+/usr/bin/curl x                             # a path to curl is still curl
+body="$(wget -qO- https://example.com)"     # commands inside $(…) are checked
+```
+
+An in-file function does not hide the real call inside it:
+
+<!-- example: {"options": {"wrapper": "retry"}, "findings": 1} -->
+
+```sh
+curl() { command curl "$@"; }               # `command curl` runs the external curl
+```
+
+### Correct
+
+With `{ wrapper: 'retry' }`:
+
+<!-- example: {"options": {"wrapper": "retry"}} -->
+
+```sh
+retry curl -fsSL https://example.com/install.sh
+retry sudo rsync -a src/ host:dst/   # retry encloses sudo, which runs rsync
+/usr/local/bin/retry curl x          # a path to the wrapper is the wrapper
+git status                           # not a network subcommand
+body="$(retry wget -qO- https://example.com)"
+echo curl                            # an argument, not a command
+curl --version                       # prints a version, touches no network
+git clone ./vendor/lib copy          # a local source
+wget() { :; }; wget x                # a function the file defines, not the client
+```
+
+## When not to use it
+
+Leave the rule off if your project has no single wrapper for network calls, or if network
+resilience is handled outside your scripts (for example by a proxy or by the CI runner). For a
+policy about commands other than network clients, define your own rule with
+[`createWrapperRule`](../wrapper-rules.md) rather than overloading `alsoTreatAsNetwork`.
+
+## Relationship to shellcheck
+
+eslint-sh is a convention and contract linter: a policy layer, where shellcheck is the gotcha
+layer. Run shellcheck beside it.
+
+shellcheck has no equivalent. It checks how commands are written, not which wrapper a project
+requires around them, and has no way to configure a project-specific wrapper. This rule exists
+because that requirement is a project contract, not a shell gotcha.

package/docs/rules/require-shebang.md

@@ -0,0 +1,157 @@
+# `sh/require-shebang`
+
+Require line 1 of every shell file to be a shebang that runs a recognized shell.
+
+| Configs | Fixable | Languages |
+| ------- | ------- | --------- |
+| `recommended`, `agent-authored` | autofix (missing shebang only) | `sh/sh` |
+
+## Rule details
+
+A script without a shebang runs under whichever shell happens to invoke it. A bash script
+started as `sh deploy.sh`, or by a tool that defaults to `/bin/sh`, then fails in confusing
+ways far from the real cause. A shebang makes the file's interpreter explicit.
+
+This rule reads line 1 of the file and reports two problems:
+
+- **`missingShebang`**: line 1 does not start with `#!`. A comment, a blank line, or
+  whitespace before `#!` all count as missing. An empty file is missing a shebang too.
+- **`unrecognizedInterpreter`**: line 1 is a shebang, but it does not run one of the
+  recognized shells: `bash`, `sh`, `dash`, `ksh`, `mksh`, `zsh` or `bats`. Each one is
+  accepted two ways:
+  - by absolute path: `#!/bin/bash`, `#!/usr/local/bin/bash`, with any arguments after it;
+  - through `env` named by absolute path: `#!/usr/bin/env bash`,
+    `#!/usr/bin/env -S bash -e`. The rule skips `env` options, their arguments and
+    `NAME=value` assignments to find the command `env` runs.
+
+  A relative interpreter such as `#!bash` or `#!env bash` is reported, because the kernel
+  resolves it against the caller's working directory, not `PATH`.
+
+A UTF-8 byte order mark before `#!` does not stop the shebang from counting.
+
+The rule does **not** check that the shebang agrees with `languageOptions.dialect`.
+`#!/bin/sh` in a file linted with `dialect: 'bash'` is accepted here. That mismatch belongs
+to [`sh/shebang-matches-dialect`](./shebang-matches-dialect.md), so one problem is never reported under two rule names.
+
+### Autofix
+
+For `missingShebang`, the fix inserts one line above line 1. The interpreter comes from
+`languageOptions.dialect`:
+
+| `dialect`          | Inserted with `style: 'env'` | Inserted with `style: 'absolute'` |
+| ------------------ | ---------------------------- | --------------------------------- |
+| `bash` (default)   | `#!/usr/bin/env bash`        | `#!/bin/bash`                     |
+| `posix`            | `#!/usr/bin/env sh`          | `#!/bin/sh`                       |
+| `mksh`             | `#!/usr/bin/env mksh`        | `#!/bin/mksh`                     |
+| `zsh`              | `#!/usr/bin/env zsh`         | `#!/bin/zsh`                      |
+| `bats`             | `#!/usr/bin/env bats`        | `#!/bin/bats`                     |
+
+The inserted line ends with the file's own line break (`\r\n` in a CRLF file). For an empty
+file the fix produces exactly the shebang line and a newline.
+
+`unrecognizedInterpreter` has no fix. The file names some other interpreter, and choosing a
+shell for it is a decision for a person.
+
+## Options
+
+This rule takes one options object:
+
+- `style` (`'env' | 'absolute'`, default `'env'`): how the autofix spells the shebang it
+  inserts. `'env'` writes `#!/usr/bin/env <shell>`, which finds the shell on `PATH`.
+  `'absolute'` writes `#!/bin/<shell>`. The option affects only the fix. Both spellings
+  are accepted when checking a file.
+
+Any other key, or any other `style` value, is a configuration error.
+
+```js
+// eslint.config.js
+{
+  rules: {
+    'sh/require-shebang': ['error', { style: 'absolute' }],
+  },
+}
+```
+
+## Examples
+
+### Incorrect
+
+<!-- example: {"findings": 1, "messageIds": ["missingShebang"]} -->
+```sh
+echo "hello"            # line 1 is a command: missingShebang
+```
+
+<!-- example: {"findings": 1, "messageIds": ["missingShebang"]} -->
+```sh
+# Deploys the site.     # line 1 is an ordinary comment: missingShebang
+echo "hello"
+```
+
+<!-- example: {"findings": 1, "messageIds": ["unrecognizedInterpreter"]} -->
+```sh
+#!/usr/bin/python3      # not a shell: unrecognizedInterpreter
+```
+
+<!-- example: {"findings": 1, "messageIds": ["unrecognizedInterpreter"]} -->
+```sh
+#!/usr/bin/env node     # env runs a non-shell: unrecognizedInterpreter
+```
+
+<!-- example: {"findings": 1, "messageIds": ["unrecognizedInterpreter"]} -->
+```sh
+#!bash                  # relative interpreter path: unrecognizedInterpreter
+```
+
+### Correct
+
+```sh
+#!/usr/bin/env bash
+echo "hello"
+```
+
+```sh
+#!/usr/local/bin/bash -euo pipefail
+echo "hello"
+```
+
+```sh
+#!/usr/bin/env -S bash -e
+echo "hello"
+```
+
+```sh
+#!/bin/sh
+# Accepted even under dialect: 'bash'; see shebang-matches-dialect.
+echo "hello"
+```
+
+## When not to use it
+
+Files that are only ever sourced (`. ./lib.sh`, `source lib.sh`) are never executed, so their
+shebang is never read. If your project keeps such libraries without a shebang, turn the rule
+off for them with `files` or `ignores` in your config:
+
+```js
+// eslint.config.js
+export default [
+  {
+    files: ['**/*.sh'],
+    ignores: ['lib/**/*.sh'],
+    rules: { 'sh/require-shebang': 'error' },
+  },
+];
+```
+
+The rule does not detect sourced libraries on its own.
+
+## Relationship to shellcheck
+
+eslint-sh is a convention and contract linter: a policy layer, where shellcheck is the gotcha
+layer. Run shellcheck beside it.
+
+shellcheck's SC2148 ("Tips depend on target shell and yours is unknown") fires when a file has
+no shebang and no `shell=` directive. shellcheck's aim is to know which shell to analyze for,
+so a `# shellcheck shell=bash` directive or a `--shell` flag silences it. This rule enforces
+the policy that the script itself names its interpreter, which a directive or a command-line
+flag does not satisfy. It also autofixes the missing line from your configured dialect.
+shellcheck's SC1008 ("This shebang was unrecognized") overlaps `unrecognizedInterpreter`.

package/docs/rules/require-strict-mode.md

@@ -0,0 +1,253 @@
+# `sh/require-strict-mode`
+
+Require a script to turn on its strict-mode shell options (`set -euo pipefail` by default, or
+`set -eu` for POSIX `sh`) within its first few statements.
+
+| Configs | Fixable | Languages |
+| ------- | ------- | --------- |
+| `recommended`, `agent-authored`, `posix-portable` (with set -eu) | autofix | `sh/sh` |
+
+## Rule details
+
+A script without strict mode keeps going after things fail. A command that fails, a variable that
+was never set, or a failed stage in the middle of a pipeline does not stop the script, so one
+failed step turns into wrong output or a damaged state further down. This rule enforces the policy
+once, at the top of the file: by default `errexit` (`-e`), `nounset` (`-u`) and `pipefail` must be
+on within the first 5 statements. Under the `posix` dialect, the default leaves out `pipefail` (see
+[Dialects](#dialects)).
+
+The rule checks the **set of options turned on**, not the literal text. All of these satisfy the
+Bash default:
+
+```sh
+set -euo pipefail
+set -o errexit -o nounset -o pipefail
+set -e; set -u; set -o pipefail
+set -ue -o pipefail
+```
+
+How the rule reads the file:
+
+- **Statements, not lines.** The window counts top-level statements from the top of the file.
+  Comments and blank lines are not statements, and `set -e; set -u` on one line is two
+  statements.
+- **Order matters.** Statements in the window apply in order, and the rule checks which options
+  are on after the last one. A `set +e` (or `set +o errexit`) in the window turns `errexit` off
+  again, so the file is reported unless a later statement in the window turns it back on. A
+  `set +e` after the window is not checked. Turning `errexit` off around one command later in the
+  script is a common, deliberate pattern.
+- **Only plain top-level `set` commands count.** A `set` in a subshell, a pipeline, or a background
+  job (`set -e &`) runs in a child process and never changes the script's options. A `set` inside a
+  function, an `if`, a loop, a `{ …; }` group or an `&&`/`||` list does not count either, even
+  though the shell may apply it there. The rule reads only plain top-level statements, so put the
+  prologue on its own line.
+- **Arguments must be static.** The rule reads `set`'s arguments as the shell does: flag clusters
+  (`-eu`, `+e`), `-o name` / `+o name`, and an `o` inside a cluster (`-euo pipefail`) that takes the
+  next word as an option name. `--` and the first argument that is not a flag end the options. When
+  an argument's value is only known at run time (`set -e "$flags"`), the rule stops reading that
+  `set` command there. Options turned on before that argument still count.
+
+The report is placed at line 1, column 1 and lists the required options that are not on.
+
+**Autofix.** The fix inserts the prologue on its own line right after the shebang, or at line 1 when
+the file has no shebang:
+
+<!-- transform: {"kind": "fix"} -->
+
+```sh
+#!/bin/bash
+cd "$1"
+# becomes
+#!/bin/bash
+set -euo pipefail
+cd "$1"
+```
+
+It uses the file's own line ending, so a CRLF file stays CRLF. The fix is
+offered only when inserting the prologue would satisfy the rule. For example, `set -e` followed by
+`set +e` in the window is reported with no fix, because the `set +e` would turn `errexit` off
+again. Decide what that `set +e` is for, then edit the file by hand.
+
+### Dialects
+
+When `mode` is not configured, the required prologue depends on `languageOptions.dialect`:
+
+| `dialect`                                    | Default prologue    |
+| -------------------------------------------- | ------------------- |
+| `bash` (the default), `bats`, `mksh`, `zsh`  | `set -euo pipefail` |
+| `posix`                                      | `set -eu`           |
+
+`pipefail` became part of POSIX only in POSIX.1-2024, and older `dash` and BusyBox `ash` builds
+still reject `set -o pipefail`. An autofix that inserted it would break a working `#!/bin/sh` script
+on those shells, so under `posix` the default requires and inserts only `set -eu`. A `posix` file
+may still turn `pipefail` on; the rule just doesn't require it.
+
+A configured `mode` always wins, whatever the dialect. To require `pipefail` in POSIX scripts too,
+configure it (see below).
+
+The dialect comes from `languageOptions`, not from the shebang. A `#!/bin/sh` file linted under the
+default `bash` dialect gets the `set -euo pipefail` default. That mismatch is reported at the
+shebang by [`sh/shebang-matches-dialect`](./shebang-matches-dialect.md); set
+`languageOptions.dialect` to `posix` for such files so the `pipefail` note above does not apply.
+
+## Options
+
+This rule takes one options object:
+
+- `mode` (`string | string[]`, default `"set -euo pipefail"`, or `"set -eu"` under the `posix`
+  dialect): the required prologue.
+  - A **string** must be a `set` command that only turns options on, such as `"set -eu"` or
+    `"set -o errexit -o nounset"`. The options it turns on are what the rule requires, and the
+    string is the exact text the autofix inserts. A string that is not such a command (for example
+    `"set +e"` or `"echo hi"`) is a configuration error.
+  - A **list** names the required options by their long names (`errexit`, `nounset`, `pipefail`,
+    `noclobber`, …, any name `set -o` accepts). The autofix inserts a `set` command built from the
+    list. Options with a one-letter flag go into one cluster in list order. The first option with no
+    letter is attached to that cluster with `o`, and any others follow as `-o <name>`. So
+    `["errexit", "nounset", "pipefail"]` inserts `set -euo pipefail` and `["errexit", "nounset"]`
+    inserts `set -eu`.
+
+    <!-- transform: {"kind": "fix", "options": {"mode": ["errexit", "nounset", "pipefail"]}} -->
+
+    ```sh
+    echo hi
+    # becomes
+    set -euo pipefail
+    echo hi
+    ```
+
+    <!-- transform: {"kind": "fix", "options": {"mode": ["errexit", "nounset"]}} -->
+
+    ```sh
+    echo hi
+    # becomes
+    set -eu
+    echo hi
+    ```
+- `withinStatements` (integer ≥ 1, default `5`): how many top-level statements from the top of the
+  file the prologue may take to appear.
+- `allowShebangOnly` (`boolean`, default `false`): when `true`, options passed to the shell on the
+  shebang line count as turned on, so a shebang alone can satisfy the rule. Shebang options combine
+  with `set` statements in the window. Only spellings the operating system passes to the shell as
+  written are read:
+  - `#!/usr/bin/env -S bash -euo pipefail`: `env -S` splits the rest of the line into words, so
+    every word after the shell name is read.
+  - `#!/bin/bash -eu`: the kernel passes everything after the interpreter as **one** argument, so
+    exactly one flag word is read. `#!/bin/bash -e -u` arrives as the single argument `-e -u`,
+    which the shell rejects, so it counts as nothing.
+  - `#!/usr/bin/env bash -e` counts as nothing. Without `-S`, Linux passes `bash -e` to `env` as
+    one command name.
+
+  It is off by default because shebang options are ignored when the script is run as
+  `bash script.sh`, so a `set` line is the only prologue that applies however the script is
+  started.
+
+```js
+// eslint.config.js
+{
+  rules: {
+    'sh/require-strict-mode': ['error', {
+      mode: 'set -euo pipefail',
+      withinStatements: 5,
+      allowShebangOnly: false,
+    }],
+  },
+}
+```
+
+For POSIX `sh` scripts that only run on shells with `pipefail` support, and should require it:
+
+```js
+// eslint.config.js
+{
+  files: ['**/*.sh'],
+  languageOptions: { dialect: 'posix' },
+  rules: {
+    'sh/require-strict-mode': ['error', { mode: ['errexit', 'nounset', 'pipefail'] }],
+  },
+}
+```
+
+## Examples
+
+### Incorrect
+
+<!-- example: {"findings": 1, "messageIds": ["missingStrictMode"]} -->
+```sh
+#!/bin/bash
+# reported: no strict-mode options are turned on
+cd "$1"
+rm -rf build
+```
+
+<!-- example: {"findings": 1, "messageIds": ["missingStrictMode"]} -->
+```sh
+#!/bin/bash
+# reported: pipefail is not turned on
+set -eu
+```
+
+<!-- example: {"findings": 1, "messageIds": ["missingStrictMode"]} -->
+```sh
+#!/bin/bash
+# reported: the set +e in the window turns errexit off again (no autofix)
+set -euo pipefail
+set +e
+```
+
+<!-- example: {"findings": 1, "messageIds": ["missingStrictMode"]} -->
+```sh
+#!/bin/bash
+# reported: a set inside a function doesn't apply to the script's top level
+main() { set -euo pipefail; }
+main "$@"
+```
+
+### Correct
+
+```sh
+#!/bin/bash
+set -euo pipefail
+cd "$1"
+```
+
+```sh
+#!/bin/bash
+# the options may be spread over statements and spelled long-form
+set -e
+set -o nounset -o pipefail
+```
+
+```sh
+#!/bin/bash
+# errexit is off for one command and back on inside the window
+set -euo pipefail
+set +e
+grep -q pattern file
+set -e
+```
+
+<!-- example: {"dialect": "posix"} -->
+```sh
+#!/bin/sh
+# with languageOptions: { dialect: 'posix' } and no configured mode
+set -eu
+```
+
+## When not to use it
+
+Turn this rule off if your project does not hold the strict-mode policy. For example, you may have
+scripts that handle every error explicitly, or files that are sourced into another shell rather
+than run, where a `set -e` would change the caller's shell. For a few files that are meant to be
+lenient, disable it with a directive comment or a `files`-scoped config entry instead.
+
+## Relationship to shellcheck
+
+eslint-sh is a convention and contract linter: a policy layer, where shellcheck is the gotcha
+layer. Run shellcheck beside it.
+
+shellcheck has no check that requires strict mode. It warns about the _consequences_ of not
+having it, case by case. For example, SC2164 flags a `cd` whose failure isn't handled, and SC2155
+flags a `local x=$(cmd)` that hides the command's exit status. This rule enforces the _policy_
+that prevents that whole class of problem, once, at the top of the file, which shellcheck's
+per-construct checks cannot express.