I needed to know when the next Pågatåg left Ystad. I was in the terminal. My phone was on the desk. The path of least resistance should have been a shell command, but there wasn't one — so I reached for the phone, unlocked it, found the app, typed my stops, waited for the API, locked it, put it down, tabbed back in. Forty-five seconds for a question that should have taken three.
I wrote a small script that calls Skånetrafiken's API from the command line so the same interaction looks like this:
$ skanetrafiken Ystad Sjöbo
📅 torsdag 16 juli 2026
07:14 → 07:57 43min · 1 byte
🚌 07:14 → 07:34 Buss 321 → Sandåkern (20min)
🚌 07:34 → 07:57 Buss 311 → Sjöbo (23min)
The code is not interesting. The interesting thing is what happens to your reflexes when you stop reaching for the phone every time you need a fact about the world.
The phone is a vortex. You go in for the bus schedule and twenty minutes later you've checked your email, scrolled three feeds, and forgotten what you opened it for. Even if you resist — even if you're disciplined — the act of picking it up, unlocking it, finding the right app, typing, waiting, locking it, and putting it down is a measurable tax on your attention. It's not that the phone can't answer the question. It's that the phone comes with a hundred other things that compete for the answer.
The terminal has no feed. It has no notifications, no algorithm, no dark pattern. It asks the question you asked and gives you the answer you wanted, and then it waits for the next question. That's the entire interaction model. You can't get distracted inside your shell prompt. You can only get back to work.
I built this thing because the friction of leaving the terminal was higher than the friction of writing a small script. That's the calculation that keeps happening if you spend your days in the shell: every time you reach for a different surface — phone, browser, GUI app — you're breaking a mode of thought. The tool just lowers the barrier to not breaking it.
The real question isn't "can my terminal do this?" It's "why would I accept a surface change for a question this small?" A bus schedule doesn't need a full-screen interface. It doesn't need an app with ratings and ads and push notifications. It needs two station names and a time, and it needs to stay out of the way after.
Most of the things we reflexively reach for our phones to do are like this. They're small queries that the shell could answer just as well, if the shell had the right vocabulary. A CLI for the bus schedule is a reminder that your workspace is extensible — and that the habit of treating every question as a phone question is a habit worth examining.
The barrier isn't the code. It's the reflex.