radion is an internet radio CLI client, written in Bash.
https://gitlab.com/christosangel/radion
Radion can be customized as far as the station selecting program is concerned. The user can choose between:
- read
- fzf
- rofi
- dmenu
Update: Introduced new feature: customizing prompt text for fzf dmenu and rofi.
Update: MacOS support added now thanks to Andrea Schäfer
Also, I was forced by my daughter to add some anime radio stations...
Update: Recording functionality added, with the use of another (you guessed it) bash script
Also options in read as Preferred selector are also case insensitive.
Any feedback is appreciated!
My first thought every time I see a pure bash project: "wow" followed by "but... why".
I get that we have bash on most machines, reducing dependencies, all that jazz. But it's so painful to do anything nontrivial with it. There are so many small potential papercuts and edge cases, I'd rather pull my teeth out with a pair of pliers than code more than a simple script in it.
That’s why it’s impressive. It’s not easy.
Oh, for sure, but to me it's "building a car with a screwdriver" impressive. It's impressive that the feat is doable at all, but why one would subject themselves to this eludes me haha.
Some people just have a natural affinity, I guess. If it made the programmer happy and it’s not full of maliciously exploitable bugs, why not?
Oh, for sure! But I'm a developer myself, so like most of us, I tend to take my technical opinions as gospel by default 😉
Sometimes it can be fun to push your limits or see how far you can go down some personally motivated rabbit hole. Just saying, I'd never do it with bash myself. Don't get me wrong, I write bash scripts all the damn time, but the second it gets more complicated than aligning a handful of simple commands without too much output parsing BS, requiring some obscure awk one liner nobody understands after 2 days, I bail out to something less awkward.
Everything is not pure bash here, it's a radio frontend for mpv. It is also using sed, awk... A standard bash use case actually.
My entire homelab env is written in "pure bash". Bare metal deployments, creation, build, deployment, update, and backup, of docker containers (which are also just convenience wrappers around other pure bash projects of mine.). Etc...
I do it because I got sick of losing data, work, workflow or convenience to black boxes I didn't create myself. Hell, even with my third party projects like Plex I have a lot of bash automation around extracting playlists from the internal sqlite db, etc. It really shifts your perspective on what's possible when you build things by hand yourself.
I've been working as a dev for 8+ years, been programming for much longer. Yes, many things are possible with bash. Many things are also possible using straight assembly, but nobody does that - for good reasons...
Many of those problems you mentioned have well established, open source solutions that should not end up in lost work or data. Building things yourself also has the downside of maintaining those things, and dealing with your own (inevitable) failures yourself too. I'd rather trust established solutions for things as complex as provisioning than roll my own. But whatever works for you.
If I were to write that much code by hand, I'd just choose something saner than bash, purely from a language perspective. That's all.
It's not like I don't use open source solutions, I use docker for example rather than automating chroots/cgroups by hand in bash. I just use them as little as possible. While you're correct, I don't lose data in a well designed open source project, I do lose work, workflow, and convenience when those projects change or shut down. What's really nice about the pure bash solutions is they're entirely portable once you have them dialed in. If I wanted to switch from docker back to vms or forward to something like harvester/rancher/k3s I'd be able to port the projects very trivially. If I built everything around one of those projects in mind, all of my work would rely on it not changing. I acknowledge it's sometimes a little more work but it's work that I get to decide when to do, not when the project maintainers decide it for me.
Not to mention the tool isn't meant to be anything more than glue between other programs
Keep in mind that what you find painful, some people find fun :)