Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Sheldon is an open-source command-line plugin manager: it manages plugin sources and generates shell code to load them when a shell starts. You configure it in a TOML file, install sources with sheldon lock, and add eval "$(sheldon source)" to your shell startup file. Its ready-made defaults target Bash and Zsh; Fish can be supported by customizing configuration.

What Sheldon does—and how shell plugins work

A shell plugin is typically a collection of shell code that adds commands, completions, prompt features, or other behavior. A plugin manager fetches or manages plugin sources and arranges for selected files to be loaded by the shell. Sheldon is neither a shell nor a plugin: it reads plugin definitions from TOML and renders shell code that loads the configured plugins.

Sheldon’s documented plugin sources include Git or GitHub repositories, Gists, remote scripts, local directories, and inline plugins. A plugin’s configuration can select a branch, tag, or revision, and use file paths or globs to choose what is loaded. Configuration can also apply templates, restrict plugins to profiles, and run pre- or post-load hooks. These are management controls, not guarantees that any given plugin is safe or compatible with your shell.

Install and initialize Sheldon

The project documents installation through Nix, Homebrew, Cargo, cargo-binstall, and prebuilt binaries. Choose the method appropriate to your system and follow its current package instructions in the official Sheldon repository. The repository’s getting-started workflow initializes a configuration for the shell you use:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
sheldon init --shell bash

For Zsh, use:

sheldon init --shell zsh

Initialization creates the TOML configuration at $XDG_CONFIG_HOME/sheldon/plugins.toml (or the corresponding Sheldon configuration location when the XDG variable is not set). Bash and Zsh have documented ready-made defaults.

Define plugins and load them at startup

Add a source

You can edit plugins.toml directly or use the add command, which adds a plugin definition to the configuration. For example, a GitHub repository can be declared in the TOML file. Follow the project’s documented syntax for the source and any options you need, such as a selected revision or the files to use.

After defining plugins, install their sources and generate the lock file:

sheldon lock

To update sources later, the documented command is:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
sheldon lock --update

Evaluate Sheldon’s generated shell code

Add this line to the startup file for your shell:

eval "$(sheldon source)"

For Bash, the usual location is .bashrc; for Zsh, it is .zshrc. When the shell starts, it evaluates the code printed by sheldon source, which loads the configured plugins. The command also checks whether the lock file is up to date, so a changed plugin configuration may require running sheldon lock before startup.

Configuration choices and reproducibility

Sheldon’s TOML configuration offers several ways to shape loading behavior:

  • Pin a source: choose a branch, tag, or revision rather than leaving the selection implicit.
  • Select files: use specific paths or globs to control which parts of a source are loaded.
  • Apply templates: use source and PATH templates, or define custom templates for different loading behavior.
  • Scope by profile: restrict a plugin to specified profiles.
  • Run hooks: configure pre- or post-hooks where the plugin workflow needs them.
  • Use inline code: define an inline plugin instead of fetching a separate repository or script.

The lock workflow separates the plugin definitions from the resolved sources: sheldon lock installs sources and generates the lock file, while sheldon source renders the code used by the shell and checks lock-file freshness. Pinning a revision can make the selected source more explicit, but it does not establish that the plugin itself is trustworthy or will work with every shell setup.

Shell support: Bash, Zsh, and Fish

The project describes Sheldon as shell agnostic, but its ready-made defaults are for Bash and Zsh. Fish support is possible by overriding configuration elements including match, apply, and templates. That makes Fish configurable; it should not be read as having the same out-of-the-box defaults or integration as Bash and Zsh.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Integration and deferred loading

Sheldon’s examples documentation states: “Because Sheldon is not written in a shell language it cannot provide the level of integration that other plugin managers can.” That is the project’s own stated trade-off, not a controlled comparison establishing that another manager is faster or better overall.

The documentation also shows deferred loading as an optional approach using the separate romkatv/zsh-defer plugin and a custom template. This is a configuration route for Zsh users who want to arrange deferred loading; it is not evidence of a quantified speed improvement. Sheldon describes itself qualitatively as fast and refers to benchmarks, but no named, attributable measurement is established here, so there is no responsible numeric speed claim to make.

Choosing Sheldon

Sheldon is a reasonable fit if you want plugin sources managed through a TOML configuration, a generated shell-loading snippet, and a lock-file workflow. When comparing it with another manager, focus on the differences that matter in your setup:

  • Shell defaults and integration: Sheldon supplies defaults for Bash and Zsh; Fish requires overrides, and the project acknowledges an integration trade-off associated with not being written in a shell language.
  • Source types: check whether you need repositories, Gists, remote scripts, local directories, or inline definitions.
  • Reproducibility and updates: consider whether configuration, pinned refs, and a lock file suit your preferred update process.
  • Configuration flexibility: assess whether templates, profiles, file selection, and hooks are useful or unnecessarily complex for your needs.
  • Deferred loading: account for the documented Zsh approach using the separate zsh-defer plugin and a custom template.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.