HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
chmln
sd
Rust2018–2026
chmln / sd

sd

Intuitive find & replace CLI (sed alternative)

26Distinct people
32Mentions
1Explicit recommenders
7.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Intuitive find & replace CLI (sed alternative)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love the idea and I'll try it out, but a heads up in case the author is around: the name sd clashes with another tool [0], which works as an alternative to sed. I use that…

pedrovhb used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year32 dated mentions

Observed mentions: 2018-12-26 22:09:31 UTC to 2026-03-24 13:09:23 UTC.

02462018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC725
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC413
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC523
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
sd - search & displace sd is an intuitive find & replace CLI. The Pitch Why use it over any existing tools? Painless regular expressions.   sd uses regex syntax that you already know from JavaScript and Python. Forget about dealing with quirks of sed or awk - get productive immediately. String-literal mode.   Non-regex find & replace. No more backslashes or remembering which characters are special and need to be escaped. Easy to read, easy to write.   Find & replace expressions are split up, which makes them easy to read and write. No more messing with unclosed and escaped slashes. Smart, common-sense defaults.   Defaults follow common sense and are tailored for typical daily use. Comparison to sed While sed does a whole lot more, sd focuses on doing just one thing and doing it well. Here are some cherry-picked examples where sd shines. Simpler syntax for replacing all occurrences: sd: sd before after sed: sed s/before/after/g Replace newlines with commas: sd: sd -A '\n' ',' sed: sed ':a;N;$!ba;s/\n/,/g' Note: this requires -A (across mode) since \n is a cross-line pattern. Extracting stuff out of strings containing slashes: sd: echo "sample with /path/" | sd '.*(/.*/)' '$1' sed: echo "sample with /path/" | sed -E 's/.*(\\/.*\\/)/\1/g' With sed, you can make it better with a different delimiter, but it is still messy: echo "sample with /path/" | sed -E 's|.*(/.*/)|\1|g' In place modification of files: sd: sd before after file.txt sed: sed -i -e 's/before/after/g' file.txt With sed, you need to remember to use -e or else some platforms will consider the next argument to be a backup suffix. Benchmarks Simple replacement on ~1.5 gigabytes of JSON hyperfine --warmup 3 --export-markdown out.md \ 'sed -E "s/\"/'"'"'/g" *.json > /dev/null' \ 'sed "s/\"/'"'"'/g" *.json > /dev/null' \ 'sd "\"" "'"'"'" *.json > /dev/null' Command Mean [s] Min…Max [s] sed -E "s/\"/'/g" *.json > /dev/null 2.338 ± 0.008 2.332…2.358 sed "s/\"/'/g" *.json > /dev/null 2.365 ± 0.009 2.351…2.378 sd "\"" "'" *.json > /dev/null 0.997 ± 0.006 0.987…1.007 Result: ~2.35 times faster Regex replacement on a ~55M json file: hyperfine --warmup 3 --export-markdown out.md \ 'sed -E "s:(\w+):\1\1:g" dump.json > /dev/null' \ 'sed "s:\(\w\+\):\1\1:g" dump.json > /dev/null' \ 'sd "(\w+)" "$1$1" dump.json > /dev/null' Command Mean [s] Min…Max [s] sed -E "s:(\w+):\1\1:g" dump.json > /dev/null 11.315 ± 0.215 11.102…11.725 sed "s:\(\w\+\):\1\1:g" dump.json > /dev/null 11.239 ± 0.208 11.057…11.762 sd "(\w+)" "$1$1" dump.json > /dev/null 0.942 ± 0.004 0.936…0.951 Result: ~11.93 times faster Line-by-line vs across mode (1M lines, ~36MB file): Command Mean [ms] Relative sd -A 'foo' 'qux' (across) 125.6 ± 14.3 1.00 sed s/foo/qux/g 316.4 ± 30.0 2.52 sd 'foo' 'qux' (line-by-line, default) 357.0 ± 15.0 2.84 Command Mean [ms] Relative sd -A '(\w+) world' '$1 earth' (across) 254.0 ± 11.2 1.00 sd '(\w+) world' '$1 earth' (line-by-line, default) 566.7 ± 16.7 2.23 sed -E 's/(\w+) world/\1 earth/g' 4432.7 ± 173.2 17.45 Line-by-line mode is ~2-3x slower than across mode but still faster than sed for regex replacements. The tradeoff is dramatically lower memory usage: Mode Peak RSS sd -A (across) 74 MB sd (line-by-line, default) 3 MB Installation Install through cargo with cargo install sd, or through various package managers Quick Guide String-literal mode. By default, expressions are treated as regex. Use -F or --fixed-strings to disable regex. > echo 'lots((([]))) of special chars' | sd -F '((([])))' '' lots of special chars Basic regex use - let's trim some trailing whitespace > echo 'lorem ipsum 23 ' | sd '\s+$' '' lorem ipsum 23 Capture groups Indexed capture groups: > echo 'cargo +nightly watch' | sd '(\w+)\s+\+(\w+)\s+(\w+)' 'cmd: $1, channel: $2, subcmd: $3' cmd: cargo, channel: nightly, subcmd: watch Named capture groups: > echo "123.45" | sd '(?P<dollars>\d+)\.(?P<cents>\d+)' '$dollars dollars and $cents cents' 123 dollars and 45 cents In the unlikely case you stumble upon ambiguities, resolve them by using ${var} instead of $var. Here's an example: > echo '123.45' | sd '(?P<dollars>\d+)\.(?P<cents>\d+)' '$dollars_dollars and $cents_cents' and > echo '123.45' | sd '(?P<dollars>\d+)\.(?P<cents>\d+)' '${dollars}_dollars and ${cents}_cents' 123_dollars and 45_cents Find & replace in a file > sd 'window.fetch' 'fetch' http.js That's it. The file is modified in-place. To preview changes: > sd -p 'window.fetch' 'fetch' http.js Find & replace across project This example uses fd. Good ol' unix philosophy to the rescue. fd --type file --exec sd 'from "react"' 'from "preact"' Same, but with backups (consider version control). fd --type file --exec cp {} {}.bk \; --exec sd 'from "react"' 'from "preact"' Edge cases sd will interpret every argument starting with - as a (potentially unknown) flag. The common convention of using -- to signal the end of flags is respected: $ echo "./hello foo" | sd "foo" "-w" error: Found argument '-w' which wasn't expected, or isn't valid in this context USAGE: sd [OPTIONS] <find> <replace-with> [files]... For more information try --help $ echo "./hello foo" | sd "foo" -- "-w" ./hello -w $ echo "./hello --foo" | sd -- "--foo" "-w" ./hello -w Processing modes By default, sd processes input line by line. This means: Low memory usage (only one line in memory at a time) Streaming output for stdin (results appear before EOF) ^ and $ match the start/end of each line without phantom matches \s+$ trims trailing whitespace without eating newlines If you need patterns to match across line boundaries (e.g. replacing \n or matching multi-line patterns), use the -A / --across flag: > echo -e "hello\nworld" | sd -A '\n' ',' hello,world Escaping special characters To escape the $ character, use $$: ❯ echo "foo" | sd 'foo' '$$bar' $bar
Read the full README on GitHub

What Hacker News says

32 sources
> Is it really "a minimalist bash program" if half the script is a forest of complicated perl regexes? [It's not half, in fact the function that Perl is in represents about 20% of the script.] *A:* Yes? Isn't it supposed to? Minimalism does not mean a lack of complexity. Since when are minimalism and complexity antonyms? Some algorithms may be minimalist but remain complex. Japan's current flag is still minimalist even though it has complicated meaning behind it. A minimalist program is generally due to the fact that it has as few features as possible, without going overboard, but also not leaving aside what everyone expects it to have. This is a small markdown reader, probably everyone expects it to handle all markdown elements elegantly (which explains REGEX) and it's in the terminal, so many hope it has pager support and handles param
Read the rest
eters appropriately. But since you didn't talk about extravagant features but about code referring to formatting, what's the real point? Is this not minimalist because the parser uses complicated regexes? If they were regexes with an easy syntax, would that be minimalist to you? Is it because they're Perl regexes, Perl regexes are maximalist but AWK regexes aren't? Or is it the complicated syntax (REGEX of [sd](https://github.com/chmln/sd) is fine?)? Or is it because "it's a forest"? So I suppose if it only had half of the current regexes, then it would be minimalist. Regular expressions are a good, objective way of handling text while keeping it simple, so how could you cover all the common Markdown syntax with a smaller forest inside a script (maybe even with just one park)? End of reply > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. (I know the site guideline says this, and although it may seem like I didn't do it, it's the original comment that seems quite illogical). But in any case, don't hesitate to disagree with me in the section below if you think I've been talking rubbish.
In [dead]
pedrovhb·Dec 31, 2022Recommendation phrase
I love the idea and I'll try it out, but a heads up in case the author is around: the name sd clashes with another tool [0], which works as an alternative to sed. I use that one pretty often, so maybe my first managed script will be one which symlinks binaries :) [0] https://github.com/chmln/sd
In SD: My script directory

Showing the 15 most recent of 32 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.