1. 43
  1.  

  2. 11

    I used to use a lot of util alternatives, but now I just stick to the standard ones: find, make, man, vim, grep, xargs, watch, etc.

    You still have to learn them anyway because they’re installed everywhere by default. You can’t always install random tools on a system.

    1. 14

      Not sure I buy this argument.

      Becoming facile with the standard available everywhere tools is a good investment, to be sure, but some of the tools cited offer a huge value add over the standard tools and can do things they can’t.

      1. 2

        In my own usage, I haven’t really noticed too much of a difference. The things I have noticed are that the non-standard tools are sometimes faster and they tend to use more common --flags. entr is a bit unique, but I’ve also been able to replace entr with watch to achieve basically the same result.

        What are some of the huge value adds that I’m missing out on?

        1. 5

          Utilities like ripgrep and fd natively respecting your .gitignore is a huge feature.

          1. 5

            Oh, man. That’s actually the feature that made me leave ripgrep. I personally prefer to not hide a bunch of information by default. Let me filter it. I didn’t even realize it did that at first. I’ve spent hours debugging something only to realize that ripgrep was lying to me. Definitely user error on my part and I eventually found you can disable that behavior. But that made me realize grep suited my needs just fine.

            1. 3

              Yep, same here. I think it’s a horrible default and easily the biggest problem I’ve ever encountered with ripgrep.

              1. 5

                I find that to be an ok default and for the odd time you don’t want that behaviour there’s --no-ignore-vcs which you can also set in your ripgrep config file

                1. 1

                  FWIW, the automatic filtering by default is one of the most highly praised features of ripgrep that I’ve heard about. (And that in turn is consistent with similar praise for tools like ack and ag.)

                  If you don’t want any filtering at all, ripgrep will behave like grep with rg -uuu <pattern>.

                  1. 1

                    I absolutely believe that, and I didn’t like it with ack and ag (yeah, I also progressed through all of them).

                    I’m not saying you didn’t do the right thing if most people like it, but it’s not for me. Thanks for ripgrep and please don’t take the above comment as any sort of attack. (and yes, I’m using the form you mentioned).

                    1. 1

                      I didn’t, no problem. Just wanted to defend my choice. :)

                2. 1

                  Hi, ripgrep author here. Out of curiosity, what made you try ripgrep in the first place? From what I hear, folks usually try it for one or both of performance and its automatic filtering capabilities. It seems like you didn’t like its automatic filtering (and I’ve tried to put that info within the first couple sentences of all doc materials), so that makes me curious what led you to try it in the first place. If you were only searching small corpora, perhaps the performance difference was not noticeable?

                  1. 1

                    In my case it was speed, in particular, replacing vimgrep

              2. 3

                watch(1) as far as I know doesn’t do anything with inotify(7), so it’s limited to a simple interval instead of being event based. As others have pointed out, you could use inotifywait(1) and some relatively simple scripts to obtain similar results.

                That being said, I still use find, grep and others regularly, these are just a little easier to work with on the daily when they’re available. fd in particular has nicer query syntax for the common cases I have.

                1. 3

                  Yeah, watch doesn’t watch (ha) for file changes, but my goal is to avoid having to rerun commands manually while I work on a file. watch(1) can achieve this goal. Yes, it’s inefficient to rerun the build every -n .1 seconds instead of waiting for file changes, but I end up reaching my goal either way, even if I have to wait 1 second for the build to start.

                  Although, I can definitely see how this could be painful if the command is extremely slow.

                  1. 5

                    I work with Python… so it goes without saying that my tests are already slow, but also many of them are computationally expensive (numpy), so they can take several minutes to complete. Obviously that’s not the same situation for everyone, use what works for you! The whole point of my post is to share tools that others may not be aware of but may find helpful.

                2. 1

                  What are some of the huge value adds that I’m missing out on?

                  Thinking about this I may have over-promised, but one thing that occurs is vastly reduced cognitive load as well as a lot less straight up typing.

                  For example I personally find being able to simply type: ag "foo" as opposed to: find . -name "*" -exec grep "foo" \; -print

              3. 5

                I’m a developer, so it’s super worth it for me to optimize my main workflow. I know the standard tools well enough that I can pretty easily revert back to them if there is one, but some of these don’t have an alternative in the standard *nix toolset. entr(1) in particular has nothing equivalent as far as I know.

                1. 3

                  How about inotifywait?

                  1. 2

                    entr is built on the same os API, inotify(7). You could probably get inotifywait to act in a similar manner with some scripting, but it does not do the same thing.

                    1. 2

                      That’s all I’ve ever used inotifywait for: watch some files or directories, and run scripts when change events occur. But I didn’t even know about entr. It does look relatively streamlined.

                      1. 1

                        Your script(s) have to implement the behavior that entr(1) implements though, so while it’s technically possible it’s far from a ‘single command’ experience, which I find very nice.

                2. 1

                  If you have to work on systems with standard tooling a lot and no option to install stuff, fair. But for me, and I think a lot of other devs, it’s pretty feasible to install non-standard tools. I almost never work on another machine than my own. Most people customize their personal machine anyway.

                  One rule I have is that scripts are always written in plain POSIX compliant shell for portability with the standard tools.

                  1. 1

                    I almost never work on another machine than my own.

                    I wonder if this is a side effect of the trends towards infrastructure as code, “cattle not pets”, containerization, etc etc etc.

                    In general I’ve found the same: the most work I do on a remote box is connecting to a running container and doing some smoke testing.

                    1. 3

                      I feel like in the era where shared UNIX hosts were more common, I would just cart binaries around in my home directory – which was often an NFS directory shared amongst many hosts as well.

                3. 10

                  It’s odd that ag and fd are suggested, but not ripgrep. fd‘s internals are based off ripgrep and once you’ve taken the first step away from regular grep -r, ripgrep is probably the most powerful/speedy alternative.

                  1. 3

                    git grep is nice if you are looking for something in a repo.

                    1. 2

                      I don’t often bookmark things, but this is up there on my main toolbar.