Hacker News Reader

Comment by leetrout | Hacker News Reader

Related, `sd` is a great utility worth the install which makes simple sed-type operations more obvious / easier (for some value of easy).

https://github.com/chmln/sd

View on HN

As soon as there is a _complete_ regex reference in the readme, it may be worth a try. The main problem with _any_ regex tool or programming language or ... is the subtle and not so subtle differences between the various regex implementations - like the "normal" and "extended" mode of sed.

This phrase:

    sd uses regex syntax that you already know from JavaScript and Python.

says it all.

I still haven't found a better short overview of various regex engines than that: https://web.archive.org/web/20130830063653/http://www.regula...

Indeed. It's different from Python, maybe JavaScript as well. https://docs.rs/regex/latest/regex/#syntax

There’s also sad that let’s you review find and replace changes to files before making them: https://github.com/ms-jpq/sad

I had to re-read your post a few times before I realized that “sad” is the name of the program

It uses a different syntax though. Hardly worth anyone's time

Not sure if I agree. Sed is widely known and much of the value comes from that, just being around for a long while, but I wouldn't really say that the syntax is all that straightforward. As a thought experiment, try explaining how to use sed to a fresh graduate who's never seen it. Not saying sd is better or anything, but rather that just because the syntax is different doesn't make it bad.

sed is widely known because it's available everywhere and is used in every shell script. I just don't see the point in learning a new utility that does the same thing as sed but with different syntax. In this case the new utility doesn't even honor my language settings and just errors out if I enter a non-English letter. It's ridiculous

How? Shouldn't it just all be UTF-8? Or do you use a different encoding on your system?

> try explaining how to use sed to a fresh graduate who's never seen it

Well, for starters, you just `s/<regex>/<replacement>/` and try to use that in your everyday work. Just forget about the syntax. It's a search-and-replace tool.

That's the only way I used sed for years. I've learned more since then, but it's still the command I use the most. And that's also what `sd` focuses on.

Also, if you want to replace newlines, just use `tr`, to hook onto the examples of sd. It may seem annoying to use a different tool, but there are two major advantages: 1. you're learning about the existence, capabilities and limitations of more tools 2. both `sed` and `tr` are probably available in your next shitty embedded busybox-driven device, while `sd` probably is not

As you said, the value comes from being around for a long time and, probably more importantly, still being present on nearly any Unix-like system.

99% of the time I use sed to mangle the output of a text file into something else.

Earlier I did this

    cat as1 | grep " 65" | sed -e 's/.* 0 65/65/' -e 's/[^ 0-9]//' |sort|uniq

Now some twat will come along and say my process should have been

    cat as1
    grep " 65" as1
    grep " 65" as1 | sed -e (various different tries to the data looks useful)
    grep " 65" as1 | sed -e (options) | sort|uniq

Because otherwise it's a "useless use of cat" and reformatting my line is well worth the time and cognitive load to save those extra forks.

I think the concept of useless use of cat is one of the few things I strongly disagree with in software development. Most things have their trade-offs, pros and cons, but using cat to start a pipe makes everything composable and easy to work with, it's pretty much universally good. The moment you drop it because of the small redundancy, you have to make sure you don't mess up the params for whatever comes next, and that overhead is in my opinion never worth what you gain by dropping cat.

“Useless use of cat” is really “useless interjection and waste of a comment”.

sd has very much proven to be worth of my time. It's both faster and way easier to use.

Middle-brow dismissal. Hardly worth anyone’s consideration.

Just go straight to the point that this isn’t available on a proprietary Unix that had its EOL fifteen years ago and that five people still use.

>this isn’t available on a proprietary Unix

Skill issue. It's not necessary in the first place anyway

Reply on news.ycombinator.com