tenrok.nl

Mastering Bash History and Expansion

Wed, 09 Sep 2026 00:00:00 GMT

History is a Bash builtin command that allows you to view, modify, and delete bash commands that have been run on the system.

Problem it solves

When you work a lot from the command shell, you probably make a lot of typos or need to re-run commands repeatedly. Bash history gives the possibility to view, modify, and delete previously used commands.

How it works

You can check this by running the following command:

# running 'which history' for me doesn't show any output (It can different output on other systems)
which history

# when typing `type history` it will tell you that the command is a shell builtin
type history
> history is a shell builtin

When a new session starts, the history file is loaded and new lines are stored in the current session’s memory. When the session is closed the list is written to disk. By default Bash uses the file ~/.bash_history to save the history to disk. The file will be overwritten by default. To append new lines you have to add the follow line to your .bashrc file shopt -s histappend.

You can configure a custom file by adding HISTFILE variable in .bashrc using the HISTFILE setting.

If you work a lot in different sessions, for example when you use tmux, the history is not synchronized, because the history lives in memory of the session. You can use the special variable PROMPT_COMMAND to append and load history lines from the history file after each command. To write lines directly to file you can add the following line to your .bashrc PROMPT_COMMAND="history -a; $PROMPT_COMMAND"

Why adding the $PROMPT_COMMAND at the end of the command? This is to preserve everything already in the $PROMPT_COMMAND variable. If you don’t add this to the command, everything already in $PROMPT_COMMAND will be replaced by history -a; and this can break other stuff.

PROMPT_COMMAND is a special variable that runs every time before bash prints your prompt. So by starting bash or after running a command bash creates a new prompt. All the content within the variable will be run.

Extend the prompt command with history -n; so new commands added from another session are automatically added to your current session’s history.

Below is an example of .bashrc with custom history settings:

# don't put duplicate lines or lines starting with space in the history.
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# setting history length
HISTSIZE=1000
HISTFILESIZE=2000

shopt is another bash builtin used to enable and disable bash specific extensions. There are a few extensions available for the history. for example you can enable histverify to let you review the command before running.

The follow shortcuts work with the history directly from the prompt:

Bash history shortcuts	Description
arrow up	go up through your sessions history
arrow down	go down through the sessions history
ctrl+R	search through the sessions history

Frequently used history commands are:

Bash history command	Description
history -a	Append the session history to the history file
history -w	Overwrite the current session history to the history file
history -r	Read the history file into the current session’s memory
history -n	Read only new lines and add them to the session’s memory
history -c	Clears the session memory list (not the file)
history -cw	Clears the session memory and write to file (clears the file also)
history [n]	Shows the last [n] commands
history -d offset	Removes lines [offset] from the list

History expansion

With history expansion you can reference and reuse previous commands using the ! expanding the command before it is executed.

A few examples are:

Bash history expansion command	Description
`!!`	the previous command in history
`!N`	number N in history
`!-N`	the N-th command back from now
`!ping`	the most recent command starting with “ping”
`!$`	the last argument of the previous command
`!^`	the first argument of the previous command
`!*`	all arguments of the previous command

> history
# Output
    1  clear
    2  echo "Hello World!"
    3  echo "Hello to the World!"
    4  echo "Hello to the World!" > world.txt
    5  history

> !2
echo "Hello World!" # expands to: echo "Hello World!"
# output
Hello World!

When I’d reach for it

Because I work a lot in the shell I constantly fall back to my history.

Gotchas

When requesting the man page for history I was a bit thrown off at first because it returned a detailed man page. This is actually the library functions used by programmers. For example Bash is using this library for there history implementation.

# when typing `type history` it will tell you that the command is a shell builtin
type history
> history is a shell builtin

To find the history documentation for bash you have to search through the man pages of bash itself.

# open the man pages for bash
man bash
# use / to search for patterns
/HISTORY
# use n to continue to the next
n

Key takeaway

The history and history expansion commands are tools that if you master the basics, it helps to be more productive and work faster on the shell. It is a quick way to reuse, and even manipulate previous commands to your benefits.

Dev Container fundamentals

Wed, 26 Aug 2026 00:00:00 GMT

A Dev container gives you the possibility to run a container as a fully functional development environment, with all the features it needs. You can use a Dev container to run an application, different tools, libraries or runtimes you need for running a codebase.

A library is code that is already written by somebody, and contains functions. From your code you call the functions from the library.
Runtimeprovides the environment the program needs to execute.
A codebase is the project containing all the code, configuration files and related assets.

The Dev container specification is built to provide rules of how to set up the Dev container, and extends with configuration files like the Dockerfile.

Specification is the rules. It describes what something should be or do.

Problem it solves

Before containers were used, developers worked directly on their local machine when developing code. At a certain time each developer’s machine is different, has different tools installed, uses different versions and has different settings.

When another developer needs to check the code, or needs to work on the same codebase this can be a pain in the ass to set the environment up on their local machine, installing all the tools necessary, and fixing any compatibility errors due to multiple overlapping versions of libraries and runtimes or even a different OS.

With Dev Containers you can specify a container environment with all the necessary tools, libraries and runtime to run, and work on the codebase and provide an instruction to start up the dev container.

Because devcontainer.json can be used by the devcontainer CLI in CI pipelines, you can run the exact same environment for automatic tests, for example with GitHub Actions. This tight integration between local dev and CI makes it easy to ship small changes multiple times a day, instead of working alone for weeks and pushing one large commit that causes conflicts and bugs.

How it works

To run a container you need a container runtime, like Docker, and a Dev container runtime like VSCode or DevPod.

To set up a devcontainer.json you can do this for example through VSCode.

Install VSCode
Install the VSCode extension Dev Containers

To create a Dev container:

Type in the search bar > Dev Container: New Dev Container
Select a container image from the list, for example python 3
Select Create Dev Container python

VSCode will now start to create the Dev container for you. When the Dev container is created it will automatically connect to it. You are now working directly in the container.

In the background the extension creates a devcontainer.json file in the .devcontainer folder inside the project folder.

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/python
{
  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:3-3.14-trixie"

  // Features to add to the dev container. More info: https://containers.dev/features.
  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  // "forwardPorts": [],

  // Use 'postCreateCommand' to run commands after the container is created.
  // "postCreateCommand": "pip3 install --user -r requirements.txt",

  // Configure tool-specific properties.
  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"
}

In the above example the image will be built based on the image specified. In this case mcr.microsoft.com/devcontainers/python:3-3.14-trixie. After the image is built the container will be created and the provided settings will be applied to the container.

For example you can add tools you want to install into the Dev container by adding them to the features section.

Some containers already have features installed in the images. You can see the images and specifications on https://github.com/devcontainers/images/tree/main/src/. python:3-3.14-trixie for example already includes node, git and zsh.

Because you run the Dev container with VSCode, it will install a version of Visual Studio Code Server into the remote container so you can connect your local VSCode to the Dev container to work on code.

You can also create the necessary files yourself. When VSCode detects them in your project folder it will ask to build or start the Dev container.

Creating the devcontainer.json only

With VSCode you also can create the necessary devcontainer.json file only.

> Dev Container: Add Container Configuration Files.. to only create the devcontainer.json
Choose to add the configuration to the workspace
Select the image you like to use (I used PowerShell for this example)
Add some features if you like, for example the Azure CLI
VSCode will create the configuration file

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/powershell
{
  "name": "PowerShell",
  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
  "image": "mcr.microsoft.com/powershell:lts-debian-11",
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {
      "installZsh": "true",
      "username": "vscode",
      "upgradePackages": "false",
      "nonFreePackages": "true"
    },
    "ghcr.io/devcontainers/features/azure-cli:1": {
      "installBicep": true,
      "version": "latest",
      "bicepVersion": "latest"
    }
  },

  "postCreateCommand": "sudo chsh vscode -s \"$(which pwsh)\"",

  // Configure tool-specific properties.
  "customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
      // Set *default* container specific settings.json values on container create.
      "settings": {
        "terminal.integrated.defaultProfile.linux": "pwsh"
      },

      // Add the IDs of extensions you want installed when the container is created.
      "extensions": ["ms-vscode.powershell"]
    }
  }

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  // "forwardPorts": [],

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
  // "remoteUser": "root"
}

After creating the configuration VSCode will detect the configuration file and ask to reopen in a Dev container.

When the container is created the following will happen:

The image will be built from mcr.microsoft.com/powershell:lts-debian-11
The configuration specifies common-utils to install zsh, set up a non-root user.
The following features will be installed:
- Zsh
- azure-cli, with Bicep
After the container is built the postCreateCommand will run. In this case it will run the command sudo chsh vscode -s \"$(which pwsh)\". This command will change the shell for the user VSCode to whatever returns from the command which pwsh, which in our case will be the location of the PowerShell shell.
In the customizations property some VSCode PowerShell settings will be applied, like installing the PowerShell extension.

More info about common-utils can be found on https://github.com/devcontainers/features/tree/main/src/common-utils

When I’d reach for it

I will reach for Dev Containers anytime I’m in need of a clean or pre-configured development environment, when I try out some new features or want to develop some PowerShell scripts. Dev containers make it also possible to work on my project regardless of the machines I’m using.

How it compares to NixOS

NixOS provides a Nix package manager that installs each package on a separate, hash-addressed path and uses that to build an environment with symlinks and references to the exact versions you declare. It runs on your own system.

There is also a NixOS distribution you can run your machine on. This will give you the possibility to make your whole machine reproducible.

So where Nix provides you with a development environment by changing your shell and environment variables, Dev Containers provide you with a whole isolated dev environment running in a container and different Linux versions, therefore Dev Containers will give you some more overhead due to image sizes.

How to setup my DevContainers using DevPod - Chezmoi and Mise

Fri, 21 Aug 2026 00:00:00 GMT

Prerequisites:

Container runtime (like docker)
IDE (vscode, vim, etc.)
Project folder with your Devcontainer project files

Install DevPod

First install devpod on your machine.

Install DevPod

curl -L -o devpod "https://github.com/loft-sh/devpod/releases/latest/download/devpod-linux-amd64" \
  && sudo install -c -m 0755 devpod /usr/local/bin && rm -f devpod

This command:

Downloads the latest devpod binary to a file named devpod
&& sudo install extends the curl command with install to install the downloaded binary
-c is ignored (not sure why it is in here)
-m accepts permissions mode as chmod
devpod the source binary to install
/usr/local/bin the install location
&& rm extends the install command wit rm to remove the downloaded binary
-f devpod removes the file named devpod

Check the installation:

Verify the installation

# use the which command to check if the installation is successful
which devpod

# outputs the location of the binary
/usr/local/bin/devpod

DevPod works with providers. A provider is the runtime where you want to run your pods. This provider is personal to you, and DevPod provides the ability to use the devcontainers on different environments.

Setup DevPod

To setup the DevPod installation for the first time you have to set a provider.

Add and select the docker provider

# add the docker provider
devpod provider add docker

# set the docker provider as default
devpod provider use docker

Adding a provider will add a provider.json file in .devpod/contexts/defaults/providers/docker. A provider is a CLI program that lets DevPod communicate with the specific engine to manage the devcontainers.

Setup the devcontainer files to include mise

Include Mise into our devcontainer setup. This will ensure that all the tools needed for the project are installed when the container is created.

These are specific settings and tools for this project. The configuration files lives within the project folder.

Chezmoi will also install Mise. The difference is that Mise installed by the devcontainer setup will install all the tools specific to this devcontainer. It looks at the /workspace/project/mise.toml file, whereas Chezmoi will install the .config/mise/config.toml

The following files are used in this setup:

devcontainer/.devcontainer.json
devcontainer/Dockerfile
scripts/setup
mise.toml

.devcontainer.json

{
  "build": {
    "context": "..",
    "dockerfile": "Dockerfile"
  },
  "postCreateCommand": "scripts/setup"
}

What this file does:

build within the build property you tell to use a Dockerfile as content to build the container.
"context": "..", is the relative path to the .devcontainer.json where the dockerbuild should be run from.
"dockerfile": "Dockerfile" is the location of the Dockerfile, relative to the devcontainer.json file.
"postCreateCommand" runs once the container is created, and this will run scripts/setup.

It is still possible to install extensions or variables through the .devcontainer.json if necessary.

.devcontainer/Dockerfile

FROM mcr.microsoft.com/devcontainers/base:ubuntu-24.04

COPY --from=jdxcode/mise /usr/local/bin/mise /usr/local/bin/

# make sure mise is activated in both zsh and bash. Might be overridden by a user's dotfiles.
RUN echo 'eval "$(mise activate bash)"' >> /home/vscode/.bashrc && \
    echo 'eval "$(mise activate zsh)"' >> /home/vscode/.zshrc

What this file does:

FROM the image to be loaded
COPY copies a file, in this case from another container --from=jdxcode/mise and copies the file /usr/local/bin/mise from this container to /usr/local/bin/ into the container.
RUN echo to put values into the .bashrc and .zshrc dotfiles

mise.toml

[tools]
bat = "latest"
kubectl = "latest"
vim = "latest"

What this file does:

[tools] tells mise to install the following tools
bat = "latest" tells mise to install bat, with the version latest

scripts/setup

#!/bin/bash

/usr/local/bin/mise trust /workspaces/$DEVPOD_WORKSPACE_ID/mise.toml && /usr/local/bin/mise install

What this script does:

#!/bin/bash set the shell to run with
/usr/local/bin/mise trust /workspaces/$DEVPOD_WORKSPACE_ID/mise.toml runs mise with the trust command to trust the mise.toml file.
&& /usr/local/bin/mise install extends the script by running mise install using the mise.toml file.
$DEVPOD_WORKSPACE_ID contains the name of the project/folder the DevPod up . command is started from.

For example when you run DevPod up . from a project folder named test-code the Workspace will be called test-code and the variable $DEVPOD_WORKSPACE_ID will be set to test-code.

Building the project

Run the following command in the directory of the project to start the devcontainer.

Build and start the devcontainer

devpod up . --ide none --dotfiles https://github.com/jackykornet/dotfiles.git

What this command does:

devpod up . start the devpod from the current directory (should be in the project folder)
--ide none the ide to use. Use none for Vim.
--dotfiles https://github.com/jackykornet/dotfiles.git the dotfiles git repo. This repo will be pulled in to the DevContainer to use.

When you choose another IDE, additional tools will be installed during the build.

When the DevPod starts, the dotfiles are pulled to the container into the ~/dotfiles directory, and it looks for a setup script to run. In my case I have a setup file in the root of my repo. The build process finds this file and executes it.

The setup file needs to be made executable beforehand chmod +x setup

In the setup file you can link dotfiles or do other stuff, like installing software. I’m going to use Chezmoi to manage the dotfile configuration. For this we have to add the following code to the setup script.

setup

#!/bin/bash

set -euo pipefail

if ! command -v chezmoi >/dev/null; then
    sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply https://github.com/jackykornet/dotfiles.git
fi

exit 0

What does this command do:

#!/bin/bash run with bash
set -euo pipefail The return code of any command in a pipeline that fails will be used as the return code of the whole pipeline, not just the last.
if ! command -v chezmoi >/dev/null checks if chezmoi is installed (echo $? will return 1 if not and the if statement fails)
sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply https://github.com/jackykornet/dotfiles.git installs chezmoi, initiates a new repo, pulls my dotfiles repo and applies the changes.
exit 0 exit 0 if no pipefail exists

See the linked blogpost for the Chezmoi setup.

The deployment process

devpod up . starts up the devpod based on the Devcontainer.json
- After the container is created it will run the postCreateCommand
  - Installs mise into the workspace
    - Install tools in workspace/mise.toml in to the workspace
- Copies dotfiles to the container
- Runs the setup script
  - Installs Chezmoi
    - Downloads the dotfiles
    - Setup dotfiles
    - Install Mise
      - Install tools into the container image

Different tool versions can be available to you based on the folder you are in.

Setting defaults

There are some default settings you can set. This is handy when you’re using the same dotfiles directory and IDE for all your devpods on a specific machine.

Set default options

# Set default URL
devpod context set-options -o DOTFILES_URL=git@github.com:you/dotfiles.git

# Set default IDE
devpod ide use none

Commands used frequently

Frequently used commands

# List workspaces
devpod ls

# SSH into workspace
devpod ssh <workspace-name>

# Delete workspace this forces fresh rebuild the next time you bring the devpod up
devpod delete <workspace-name>

# Stop the workspace
devpod stop <workspace-name>

# use the --recreate parameter to recreate a devpod
devpod up . --ide none --dotfiles https://github.com/jackykornet/dotfiles.git --recreate

##
## Mise
##

# Install new packages with mise
mise install

# List all installed packages
mise list

##
## Chezmoi
##

git add .

# commit changes
git commit -m "message"

# push to repo
git push

For consideration

When installing a package with Mise you can do this with mise install this will add the packages to the mise.toml file automatically. When you add packages to be installed through Chezmoi you have to do this in the dot_config folder of the working directory and then commit and push the changes to git to make the change available after a rebuild.

How to setup my local machine with Chezmoi and Mise

Fri, 21 Aug 2026 00:00:00 GMT

Install Chezmoi manually

The following command will install Chezmoi on my machine, apply my dotfiles repo to configure all my dotfiles, install Mise, and use Mise to install any tools I’d like installed by default.

# run the following command to install chezmoi and apply my dotfiles.
sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply https://github.com/jackykornet/dotfiles.git

What is happening:

sh -c "$(curl -fsLS get.chezmoi.io)" downloads the binary and installs the latest version of Chezmoi.
-- passes parameters to the Chezmoi installation. If parameters are passed, Chezmoi starts after the installation with these parameters.
init initiates a new installation
--apply https://github.com/jackykornet/dotfiles.git applies an existing dotfiles repo to the home directory

Adding --apply is the same as running Chezmoi apply. The following is happening (in order of application):

Checks the state of the source (this is the working directory $HOME/.local/chezmoi, and the place where the git repo is pulled)
Checks the state of the destination. (this is the home directory where the actual dotfiles live)
Computes the target state (the difference between the source and destination).
Applies updates to the target. The order of application is based on alphabetic order. Target names are considered after all attributes are stripped.
- First it will run all the scripts with the before attribute before_
- Then it will process all the other files and scripts
- At the end all the after_ scripts will run.

When not applying the —apply parameter Chezmoi will only copy the files to the working directory, so you can check the difference between the source and destination before running Chezmoi apply manually.

Script attributes

There are multiple script attributes available, running at different times in the process.

run_before_ — run before everything else.
run_once — run once if success and not changed.
run_onchange — run only on change. Can also be used for tracking changes of external files.

It is also possible to combine attributes together.

run_once_before_ — run once before anything else
run_onchange_after_ — run onchange after anything else

See https://www.chezmoi.io/reference/source-state-attributes/ for all possible attributes

Install Mise

With .chezmoiexternals external programs can be installed. To install Mise create a file in .chezmoiexternals with the .toml extension.

tree — file tree of the .chezmoiexternals directory

.
├── .chezmoiexternals
│   └── mise.toml

Add the configuration for the installation of the Mise binary.

content of the mise.toml file

[".local/bin/mise"]
type = "file"
executable = true
url = "https://mise.jdx.dev/mise-latest-{{.chezmoi.os}}-{{.chezmoi.arch}}"

What this file does:

[".local/bin/mise"] installs the program to this location
type = "file" as a file
executable = true makes the file executable
url = "https://mise.jdx.dev/mise-latest-{{.chezmoi.os}}-{{.chezmoi.arch}}" from this URL.
- Templating variables are used to get the right installation package, based on the os and architecture of the machine.

All the possible template variables can be seen by running the command chezmoi data

Install tools with Mise

To manually install tools with Mise run the command $HOME/.local/bin/mise install. This will install all tools specified in .config/mise/config.toml.

To install tools automatically using Chezmoi use a run_onchange_after script. Create a file run_onchange_after_install_packages.sh.tmp in .chezmoiscripts.

├── .chezmoiscripts
│   └── run_onchange_after_install_packages.sh.tmpl

Add the following content to the file

run_onchange_after_install_packages.sh.tmp

#!/bin/bash
# packages hash: {{ include "dot_config/mise/config.toml" | sha256sum }}
$HOME/.local/bin/mise trust $HOME/.config/mise/config.toml && $HOME/.local/bin/mise install

To check if a file is changed Chezmoi is creating a hash of the file content. When the hash changes, the file is changed and it will run again. It is also possible to include external files into the hash by adding the following line.

What this file does:

# packages hash: {{ include "dot_config/mise/config.toml" | sha256sum }} includes dot_config/mise/config.toml in the hash calculation.
$HOME/.local/bin/mise trust $HOME/.config/mise/config.toml trusts the config file.
$HOME/.local/bin/mise install runs mise install to install the tools.

When dot_config/mise/config.toml changes, the hash will change and the run_onchange_after_install_packages.sh.tmp script will run again.

Why the order of trust matters

By default Mise doesn’t use any external configuration files unless instructed to do so. This is to prevent any harmful scripts from being executed from untrusted sources. If we do not first trust the config.toml file before running install, Mise will not process the config.toml.

Files and folders

This is a brief overview of the most valuable files and locations used by Chezmoi and Mise

What	Where
Chezmoi binary (by Mise)	~/.local/share/mise/installs/chezmoi/latest/chezmoi
Chezmoi binary installed by hand	{$PWD}\bin\chezmoi
Chezmoi source directory	~/.local/share/chezmoi
Mise binary	~/.local/bin/mise
Mise tools binary	~/.local/share/mise/installs/
Mise config file	~/.config/mise/config.toml
dot_file files	~/.file
dot_config folder	~/.config/
dot_config/anything	~/.config/anything

Git repo structure

A brief explanation of the git repo structure and how Chezmoi processes them.

dotfile repo structure

dotfiles/
├── .chezmoiexternals      #-- external script location
│   └── mise.toml
├── .chezmoiignore         #-- files to ignore
├── .chezmoiscripts        #-- script to run during apply
│   └── run_onchange_after_install_packages.sh.tmpl
├── README.md
├── dot_bashrc             #-- will be copied to ~/.bashrc
├── dot_config             #-- everything inside will be copied to ~/.config. If .config doesn't exist it will be created.
│   ├── mise
│   │   └── config.toml    #-- will be copied to ~/.config/mise/config.toml
│   └── starship.toml
├── dot_vimrc              #-- will be copied to ~/.vimrc
└── setup                  #-- DevPod bootstrap (must be executable). Ignored by Chezmoi (see .chezmoiignore)

Useful Commands

An overview of the most useful commands you use while working with Chezmoi or Mise

## Chezmoi

# cd in to chezmoi source dir, same as cd ~/.local/share/chezmoi
chezmoi cd

# Apply dotfiles locally
chezmoi apply

# Dry run with verbose logging. Does not apply anything.
chezmoi apply --dry-run --verbose

# Shows the difference between the working dir and home directory
chezmoi diff

# Pull :latest from remote and runs apply
chezmoi update

# Add a managed file (copies the existing file to dot_bashrc)
chezmoi add ~/.bashrc

# Edit a managed file
chezmoi edit ~/.bashrc

# Remove run_once states, all scripts run again after apply
chezmoi state delete-bucket --bucket=scriptState
chezmoi apply

# The git commands to use after changing dotfiles.
# add to staging
git add .

# commit changes
git commit -m "message"

# push to repo
git push

##
## Mise
##

# List installed tools
mise list

# Shows trusted config files
mise trust

# Trust config file ~/.config/mise/config.toml
mise trust ~/.config/mise/config.toml

# Install tools from config.toml
mise install

# Add a tool (adds it also to config.toml)
mise use bat@latest

tenrok.nl

Mastering Bash History and Expansion

Problem it solves

How it works

History expansion

When I’d reach for it

Gotchas

Key takeaway

Dev Container fundamentals

Problem it solves

How it works

Creating the devcontainer.json only

When I’d reach for it

How it compares to NixOS

Links

How to setup my DevContainers using DevPod - Chezmoi and Mise

Install DevPod

Setup DevPod

Setup the devcontainer files to include mise

Building the project

The deployment process

Setting defaults

Commands used frequently

For consideration

Links

How to setup my local machine with Chezmoi and Mise

Install Chezmoi manually

Script attributes

Install Mise

Install tools with Mise

Why the order of trust matters

Files and folders

Git repo structure

Useful Commands

Links