Hacker News Reader

Comment by petecooper | Hacker News Reader

Somewhat related - `duf` is "a better `df` alternative":

Even though it's not supposed to be my day job, I've ran `df |grep -v <super long list` hundreds of times in the past year, yet it never occurred to me that I could try and find a better tool.

Preach. This happens to me all the time and keeps happening.

There's a lot of Unix/Linux stuff that I wish I could UNlearn, I'm aware of other tools but muscle memory keeps me using worse things.

(honestly, I also feel this way about vim as well as 'writing in cursive')

I feel you.

I still `cat foo | grep bar` instead of `grep foo bar`

The reason I stick to `cat foo | grep bar` is that I am never quite sure if `grep bar foo` would be correct instead (it is).

The file argument is usually the last so that you can do eg `grep foo -- *`

I remember it as "grep for a needle in a haystack"

But to me -- this is different?

I believe "useless use of cat" is FAR MORE useful than what the ultra-nerds say; I could care less about "saving a few characters."

The mental model of the pipeline --in one end and out the other -- is entirely too usefully intuitive and way better than some imaginary geek-cred.

(I was more thinking about the new rust tools, e.g. rg instead of grep)

Plus sometimes you want to throw something like `pv` in.

Plus the regex is more likely incorrect in the first attempt and needs to be fixed.

The former has one big advantage: I can easily change "needle" without having to skip all over the cmdline...

Pretty usefull when debugging something interactively.

Might help to replace

    cat foo | $command

with

    <foo $command

It's the same order, but I think $command can sniff what kind of file stdin is, and optimize.

Actually instead of `grep bar foo`.

Installing a new tool just to exclude certain parts of the list has much more friction involved than just making a shell alias/function/script though. It's also much more portable.

If it's possible to include (rather than exclude), you can:

    $ df /dev/sda1 /dev/nvme0n1p1

And get only those file systems.

And more importantly, you can specify fs locations, so `df / /home` for example

`df|grep` might be “the better tool” because the cognitive overhead of knowing an extra program’s interface.

You’re just saying “show me the subset of this other list” and you automatically select your go-to solution for that: `|grep`

The reason for seeking a better tool is when too much excessive work (== time) is involved, or list generation has side effects. But in this case you don’t have two million mount points, so no need to worry.

I also like https://github.com/Byron/dua-cli, does disk usage like du but also has an interactive mode which makes finding and freeing up space a breeze.

I've always used ncdu for this. It also allows deleting files/directories for when you're trying to figure out how to free up space.

https://en.wikipedia.org/wiki/Ncdu

For anyone that likes ncdu I would highly recommend gdu. https://github.com/dundee/gdu

And `dust` as a `du` replacement.

Also `dua`[0] is a great `du` replacement which is must faster on modern NVMe drives. It includes an interactive mode `dua i` which I'd frame as a `ncdu` replacement.

[0] https://github.com/Byron/dua-cli

Started using dust yesterday and like it so far. Also a big fan of diskus by sharkdp as a blazingly fast du -hs alternative

replacement?

why not make df better...

And miss the chance to rewrite it in Rust or Go? :)

Jest aside, it's much easier to write a small tool from scratch, than to contribute to coreutils, where this kind of improvement is likely to be rejected, for various arguably valid reasons.

Besides, having alternatives is healthy for the Linux ecosystem, and writing something from scratch is a good learning experience.

Making a new tool means you can break backwards compatibility.

Better is also subjective.

Reply on news.ycombinator.com