Related, `sd` is a great utility worth the install which makes simple sed-type operations more obvious / easier (for some value of easy).<p><a href="https://github.com/chmln/sd">https://github.com/chmln/sd</a>
> Why sed??<p>> Sed is the perfect programming language, especially for graph problems. It's plain and simple and doesn't clutter your screen with useless identifiers like if, for, while, or int. Furthermore since it doesn't have things like numbers, it's very simple to use.<p>"useless identifiers like if, for, while, or int"? Useless identifiers?
Once in HN comments I saw `sed` referred to as a one-way hashing function, and that's always stuck with me - not just for sed, but for any type of operation that ends up being sort of a "black box". Input becomes output reliably, but it's hell to understand how. My big take away was: These types of operations are OK, when necessary, but it's a good idea to take the time to write some comments/documentation so the next person who looks at it (including self) has somewhere to start.<p>That said, debugging is definitely a thing, and tools like this are awesome!
I am done with regular expressions languages and engines. Each time I wanted to do a not so trivial usage of it, I had to re-learn the language(s) and debug it, not to mention the editing operations on top of them (sed...).<p>This has been quite annoying. So now I code it in C or assembly fusing common-cases code templates and ready build scripts to have a comfortable dev loop.<p>In the end, I get roughly the same results and I don't need those regular expressions languages and engines.<p>It is a clear win in that case.
Oh, I definitely need to run this one on <a href="https://github.com/chebykinn/sedmario">https://github.com/chebykinn/sedmario</a>
Amusingly, in French, "desed" sounds like "décéde", which means die / decease. That's quite a fitting name for a tool one would use in "I need to debug a sed script" situations!
I feel we're witnessing a resurgence of interest in 'nix default programs such as `sed` and `awk` in part because LLMs make it so much easier to get started in them, and because they really do exist <i>everywhere</i> you might look. (The fact they were designed to be performant in bygone decades and are super-performant now as a result is also nice!)<p>There is just something incredibly freeing about knowing you can sit down at a freshly-reinstalled box and do productive work without having to install a single thing on the box itself first.<p>EDIT: <a href="https://hiandrewquinn.github.io/til-site/posts/what-programming-languages-come-out-of-the-box-on-debian-12/" rel="nofollow">https://hiandrewquinn.github.io/til-site/posts/what-programm...</a> might be of interest if you want to know what you can work with right out of the box on Debian 12. Other distros might differ.
sed, awk, grep and friends are just so effective at trawling through text.<p>I dump about 150GB of Postgres logs a day (I know, it's over the top but I only keep a few days worth and there have been several occasions where I was saved by being able to pick through them).<p>At that size you even need to give up on grepping, really. I've written a tiny bash script that uses the fact that log lines start with a timestamp and `dd` for immediate extraction. This allows me to quickly binary search for the location I'm interested in.<p>Then I can `dd` to dump the region of the file I want. After that I have an little awk script that lets me collapse the sql lines (since they break across multiple lines) to make grepping really easy.<p>All in all it's a handful of old school script that makes an almost impossible task easy.