Live data from Hacker News

Modern Linux tools

ikrima.dev

71–80 of 219 posts

Re: Modern Linux tools

#71
post #62
post #60

Earlier quoted context omitted.

> But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one li…

`find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc

[deleted]

Re: Modern Linux tools

#72
post #61
post #14

I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. I genuinely don't know what is going on here.

> I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. > I genuinely don't know what is going on here. I basically live in my music library. However, every single pop artist offers songs that I don't like, are not in my library, and mysteriously have many…

> Joking aside, have you ever tried to use some of these tools

No.

> I use to not understand why people where using vim until I really tried.

There's your problem. I respectfully suggest installing Emacs.

Re: Modern Linux tools

#73
post #67

Earlier quoted context omitted.

Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…

grep -ri foo ./* Hits in hidden files is not really a pain point for me

Curious if that answers the "I genuinely don't know what is going on here" then? Not searching hidden files (or third-party dependencies, which `rg` also does automatically with its ignore parsing) isn't just a nice to have, it's mandatory for a number of tasks a software engineer might be performing on a code base?

Re: Modern Linux tools

#74
post #14

I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. I genuinely don't know what is going on here.

Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…

Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`:

   find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar
(This one I could do from muscle memory.)

If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me switch `xargs` for `find`'s own `-exec` functionality:

   find . -path '*/\.*' -prune -o -type f -name "*.foo" -exec grep bar {} +
(I had to look that one up.)

Re: Modern Linux tools

#75
post #68

As someone who logs into hundreds of servers in various networks, from various customers/clients, there is so little value in using custom tooling, as they will not be available on 90% of the systems. I have a very limited set of additional tools I tend to install on systems, and they are in my default ansible-config, so will end up on systems quickly, but I try to keep this list short and sweet. 95% of the systems I…

Another reason emacs as an OS (not fully, but you know) is such a great way to get used to things you have on systems. Hence the quote: "GNU is my operating system, linux is just the current kernel".

As a greybeard linux admin, I agree with you though. This is why when someone tells me they are learning linux the first thing I tell them is to just type "info" into the terminal and read the whole thing, and that will put them ahead of 90% of admins. What I don't say is why: Because knowing what tooling is available as a built-in you can modularly script around that already has good docs is basically the linux philosophy in practice.

Of course, we remember the days where systems only had vi and not even nano was a default, but since these days we do idempotent ci/cd configs, adding a tui-editor of choice should be trivial.

Re: Modern Linux tools

#76
post #67

Earlier quoted context omitted.

Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…

grep -ri foo ./* Hits in hidden files is not really a pain point for me

That doesn't apply to the very specific case for which the parent asked a solution.

Re: Modern Linux tools

#77
post #69

I always enjoy these lists. I think most folks out there could probably successfully adopt at least one or two of these tools. For me, that’s ripgrep and jq. The former is a great drop-in replacement for grep and the latter solves a problem I needed solving. I’ll try out a few of the others on this list, too. lsd and dust both appeal to me. I just enjoy seeing others incrementally improve on our collective tool chest…

I think many of us linux admins have such a list. Mine in particular is carefully crafted around GPL-izing my stack as much as possible. I really like the format of this ikrima.dev one though! The other stuff is great too, worth a peruse.

Re: Modern Linux tools

#78
post #14

I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. I genuinely don't know what is going on here.

Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…

  find . -type f -name '*.foo' -not -path '*/.*' -print0 | xargs -0 grep bar

Re: Modern Linux tools

#80

Earlier quoted context omitted.

Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…

Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`: find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar (This one I could do from muscle memory.) If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me…

Thanks yeah this is a good example of why I prefer the simpler interface for `rg` and `fd`. Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface.

For the record, I think `git grep` is probably the best builtin solution to the problem I gave, but personally I don't know off-hand how to only search for files matching a glob and to use the current directory rather than the repository root with `git grep` (both of which are must haves for me). I'd also need to learn those same commands for different source control systems besides git (I use one other VCS regularly).

Post reply on HN