HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bitfield
script
Go2019–2026
bitfield / script

script

Making it easy to write shell-like scripts in Go

16Distinct people
21Mentions
0Explicit recommenders
7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Making it easy to write shell-like scripts in Go

GitHub

Where it is used

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

What people are saying

No recommendation phrase was found in the indexed comments.

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

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 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 year21 dated mentions

Observed mentions: 2019-06-10 15:19:55 UTC to 2026-01-07 22:47:15 UTC.

024682019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 5 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 8 mentions; 5 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 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
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC550
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC853
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC110
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

21 sources
Same here, and I periodically research but remain disappointed; people usually just write a tool to address their current pet peeve and 1-2 years later the tool is of course abandoned. Using just[0] as a task runner has solved a lot of per-project-scripts problems for me but it still cannot do DAG analysis + parallel task running of tasks not blocked on each other (or allow you to opt into serial or parallel task running). So it remains firmly in just the "task runner" territory. I know many people would jump at the opportunity to say "just learn `make`!" but no thanks, I value my sanity. `make` is also inheriting a lot of bash-ism weirdness which makes it even worse. The mage[1] tool that uses `Magefile`-s might be it but it's a bit more verbose (as it's Golang) and I am not sure how well does it integrate with the shell. Maybe script[2]
Read the rest
can be used to complement it. Sadly I don't have the time (and lately the inclination) to experiment but there are tools out there and I wish we finally started unifying things. [0] https://github.com/casey/just [1] https://magefile.org/magefiles/ [2] https://github.com/bitfield/script
In I am not yet ready to switch to Zig from Rust
That's why I plan on migrating all my shell scripts to Golang programs f.ex. using https://github.com/bitfield/script -- it already has a number of simulations of shell commands and I'd contribute others if I had the time. sh / bash / zsh scripts are just fragile and that's the inconvenient truth. People who devised the shell interpreters had good intentions but ultimately their creations grew to a scope 1000x bigger than they intended, hence all the "do X but if Y flag is set then do Z... unless flag A is also set in which case do Y and part of Z". It's horrendous and I seriously don't get what's so difficult in just coding these scripts in a programming language that provides single statically linked binaries (like Golang) and just distribute it with your images -- or run them in CI/CD and have init containers and never include them in
Read the rest
the images in the first place. Inertia, of course. But I'll be actively working against it until I retire.
In Using ARG in a Dockerfile – beware the gotcha
I believe error handling looks like this: package main import ( "github.com/bitfield/script" ) func main() { _, err := script.Stdin().Column(1).Freq().First(10).Stdout() if err != nil { log.Fatal(err) } } Errors are "remembered" by the pipeline and can be processed when you get to a sink method.
In Scripting with Go (2022)

Showing the 15 most recent of 21 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.