Command-line tools for web development

The command line remains the fastest place to search, filter and manipulate code. Yet the historic Unix tools — grep, find, cat — date from an era without .gitignore, without 400 MB node_modules directories and without coloured output. A generation of replacements has taken hold in web development environments. Here are the ones that genuinely earn a place in a $PATH.

#Searching and filtering

#ripgrep — the search grep should have been

rg recursively searches a regular expression while automatically respecting .gitignore, skips binary files and colours its output. Written in Rust by Andrew Gallant, it powers the default search in Visual Studio Code, which is a fair guarantee of large-scale exercise.

# Search for a function call across the project, without wading through node_modules
rg "wp_enqueue_script" --type php

# List matching files
rg -l "TODO" src/

# Regular expression with capture, replacement shown without writing
rg "version: (d+.d+)" --replace 'v$1'

The gap with grep -r is not only raw speed but .gitignore awareness: on a monorepo, grep spends seconds walking vendor/ and node_modules/ that rg ignores by default. The official repository documents the file-type filters.

What ripgrep buys is not typing comfort: it is the speed at which you understand an unfamiliar codebase.

#fd — finding a file without reciting find’s syntax

find is powerful and its syntax is punishing. fd, written by David Peter, handles the common case simply: readable syntax, coloured output, .gitignore awareness.

# All SCSS files
fd -e scss

# Find and remove leftover .DS_Store files
fd -H '^.DS_Store$' -X rm

# Look for a specific directory
fd -t d migrations

#fzf — the fuzzy filter that composes

fzf, by Junegunn Choi, is an interactive fuzzy filter. Useful on its own, it comes into its own combined with other tools through pipes: history navigation, Git branch selection, file opening.

# Open a fuzzy-selected file in $EDITOR
vim "$(fzf)"

# Switch Git branch interactively
git checkout "$(git branch | fzf | tr -d ' *')"

# Combined with fd and bat as a preview
fd -t f | fzf --preview 'bat --color=always {}'

#Reading and understanding

#bat — cat with syntax highlighting

bat replaces cat for human reading: syntax highlighting, line numbers, Git markers in the gutter. For scripting, cat remains preferable; for reading a configuration file, the gap is clear.

bat wp-config.php
bat -r 40:80 functions.php   # lines 40 to 80 only

#eza — a contemporary ls

With exa no longer maintained, the community picked up development under the name eza: icons, colours by type, tree display, a Git status column.

eza -la --git --icons
eza --tree --level=2 src/

#jq — working with JSON

As soon as an API is involved, jq becomes hard to avoid. The project, now maintained under the jqlang organisation, has returned to a regular release cadence.

# Extract post titles from the WordPress REST API
curl -s https://example.com/wp-json/wp/v2/posts | jq '.[].title.rendered'

# Filter and reshape
curl -s https://example.com/wp-json/wp/v2/posts 
  | jq '[.[] | {id, slug, title: .title.rendered}]'

#gh — GitHub without leaving the terminal

GitHub’s official client covers most of the workflow: creating a pull request, reviewing, checking continuous integration runs, managing issues. It removes the constant round trip between editor and browser.

gh pr create --fill
gh pr checks
gh issue list --label bug

#Summary

#What to take away

None of these tools provides a capability that did not exist before: they lower the cost of operations performed dozens of times a day. That is precisely what makes them pay off — and what explains their adoption in toolchains as widespread as Visual Studio Code’s.

#Also on Mail Studio

• CloudPanel: self-hosted WordPress without a heavyweight panel
• Editorial agents in production: what holds and what breaks