Use Bun for Shell Scripts

me@iany.me (Ian Yang) — Sat, 07 Feb 2026 00:00:00 +0800

I’ve moved most of my small scripts to Bun. It sidesteps Windows’ lack of shebang support and the Git-for-Windows/WSL bash dance, and gives you one runtime for both ad-hoc shell-style commands and full scripts.

Problems Bun solves

Windows doesn’t execute #!/usr/bin/env python3 or #!/bin/bash, so scripts written for Linux or macOS usually need a separate PowerShell version. Bun compiles JavaScript to native executables, so a single script can run cross-platform without shebangs.

Mise file tasks have started to support shebangs on Windows in the latest release, but they rely on system bash.exe, which often points at WSL. Bun does not. You run bun ./script.js and embed shell commands via Bun.$; the script uses Bun’s bundled bash environment.

Why Bun for shell scripts

The command bun build ./script.ts --compile --outfile script produces a single binary, so no shebang or interpreter is needed on Windows. The Bun.build API is available too; I use a build.js script to walk a directory and compile all executables. Pre-built binaries start quickly—Bun’s docs cite ~5ms vs Node’s ~25ms for a simple script, which helps for small, frequently run scripts.

Bun has strong support for shell-style scripting. Bun Shell runs bash commands; the main entry point is Bun.$, which constructs shell commands from template literals for safe interpolation, similar to google/zx. On Windows, Bun ships with MSYS, so you get a consistent bash environment and common Linux CLI tools without extra setup.

Other useful features:

Bun.secrets—Securely store and retrieve secrets using the OS keystore (Windows Credential Manager, macOS Keychain, Linux libsecret). Secrets - Bun
Built-in support for glob patterns, YAML parsing, ANSI colors, and more. Bun Runtime

Short example

import { $ } from "bun";
const out = await $`echo hello`.text();
console.log(out); // hello

Run it with bun run script.js or bun ./script.js.

Obsidian Notes

JavaScript Shell Scripting

My Windows Environment Setup

me@iany.me (Ian Yang) — Sun, 03 May 2020 22:03:22 +0800

I have only one Windows device, the Surface Go. I work on it occasionally, especially on short trips. I prefer Surface Go because of handwriting. I have a simple setup to meet my work requirements.

I spend the most time on a computer in three apps: terminal, text editor and web browser. I use Windows Terminal, Visual Studio Code and Chrome in Windows.

I use ColorTool to convert my favorite theme PaperColor into Windows Terminal schema. This is my full Windows Terminal config file.

Since I don’t do heavy development locally, I use PowerShell as default in the Windows Terminal. The command echo $profile will print the PowerShell config file path. The essential PowerShell config is enabling the Emacs style keybinding (full version here).

Set-PSReadLineOption -EditMode emacs

Scoop is very handy to install essential command line utilities, for example:

scoop install mingit ripgrep

I use the OpenSSH Client component in Windows, which can be enabled in “Settings / Apps / Manage optional features”. I used to set an SSH passphrase, but the ssh agent service is disabled. It can be enabled in PowerShell ran as admin:

# Run once as admin
Get-Service ssh-agent | Set-Service -StartupType manual

I have set the startup type to manual, so if I want to load the key, I have to start the service first:

Start-Service ssh-agent
ssh-add

However, the git installed by scoop uses its own bundled ssh client by default. It is easy to fix it by setting an environment variable GIT_SSH.

# Run once as logged in user
$SSHPath = (Get-Command -Name 'ssh.exe').Source
[Environment]::SetEnvironmentVariable('GIT_SSH', $SSHPath, 'User')

Restart Windows Terminal and now git will use the key in ssh agent.

Git has the same issue with GPG. Use git config to tell where the GPG program is:

git config --global gpg.program (Get-Command -Name 'gpg.exe').Source

Following is a list of other apps I used in Windows: