bat, fd, hexyl, hyperfine

I'm going to take this moment to remind all of you well-paid engineers that if we each spread $10 a month sponsoring talented software makers like sharkdp the Internet would be a better place.

So many great little tools out there and we should try to support an ecosystem for them.

find -> fd, time(for runtime comparison) -> hyperfine, grep->ripgrep, asciinema + converting to .gif -> t-rec[1], manually creating convertional commits -> koji[2], etc.

[1]https://terminaltrove.com/t-rec/ [2]https://terminaltrove.com/koji/

Since I believe the correlation of usage of these tools is high, I think they could benefit from having similarly named flags.

fd - https://terminaltrove.com/fd/

bat - https://terminaltrove.com/bat/

numbat - https://terminaltrove.com/numbat/

hyperfine - https://terminaltrove.com/hyperfine/

hexyl - https://terminaltrove.com/hexyl/

we make a real effort to ensure that you can install them with the ability to see the screenshots.

For me, anything that isn’t a drop-in replacement for the OG tools isn’t worth the friction. I use ripgrep inside VS Code but vanilla grep on the command line because of years of muscle memory.

That said, I don’t care what language a tool is written in as long as it works. One of my favorite Unix tools is GNU Stow, and it’s written in Perl. Even if these Rust tools were drop-in replacements, I probably wouldn’t bother installing them manually. As a user, the speed improvements and memory safety don’t really matter to me.

There are other languages, like Go, where memory safety is guaranteed as well, and Go’s performance is more than adequate for tooling—with the added benefit of getting more engagement from the community. So I’m not entirely convinced by this “Rust is the savior” narrative.

That said, if macOS or Ubuntu decided to hot-swap the OG tools with Rust alternatives that behave exactly like their predecessors, I probably wouldn’t complain—as long as it doesn’t disrupt my workflow.

I know fd has options to not ignore things, but I can never remember them, so I just go back to find because I know it'll search everything.

find . | grep what_i_am_looking_for

Because I can never remember how finds arguments work. I like the integrated xargs like behavior as well.

One thing I did not see in there was how fd handles symlink directory traversal? Searched the whole readme for it, and only found options to match on symlinks or not.

I’m 100% on board with this recent-ish trend toward new replacement utilities that may or may not retain all of the flexibility of the originals but are vastly easier to use for common cases.

https://ss64.com/mac/mdfind.html

Interestingly, the author is listed as one of the maintainers of `fd` as well.

    COMMAND                                 OUTPUT    WALLCLOCK_SEC     USR_SEC    SYS_SEC
    time find ~ -iregex '.*\.jpg$' | wc -l  14372             45.04        4.59      13.23
    time find ~ -iregex '.*\.jpg$' | wc -l  14372             48.42        4.60      13.59
    time find ~ -iname '*.jpg' | wc -l      14372             44.55        1.07      13.57
    time find ~ -iname '*.jpg' | wc -l      14372             44.94        1.08      13.64
    time fd '.*\.jpg$' ~ | wc -l            14325              4.01        2.67      24.16
    time fd '.*\.jpg$' ~ | wc -l            14325              4.37        2.73      30.28
    time fd -g '*.jpg' ~ | wc -l            14325              3.98        2.72      25.84
    time fd -g '*.jpg' ~ | wc -l            14325              4.04        2.69      26.82

So not dual-licensed (MIT OR Apache-2.0), but MIT AND Apache-2.0? That's unusual.

Later: it seems they intended dual-licensing, and botched the wording: https://github.com/sharkdp/fd/issues/105

  # Find file by prefix (ignore case). 
  # Usage: 'f' or 'f myfile' or 'f myfile.txt \etc' 
  # or f '*css'

  function f() {
    find ${2:-.} -iname "${1}*" 2>/dev/null | grep '^\|[^/]*$'
  }

  # We use noglob, so zsh doesn't expand characters like "*" 
  # and so we can do e.g. f *css
  alias f='noglob f'

I eventually gave up! Thats how ergonomic find is :)

I feel like awk could be so much better.

Hyperfine is another underrated gem that is just so great.

[0] https://github.com/luckman212/alfred-pathfind/

`fd` isn't one of those.

`fd` is amazing.

It is simpler, faster and easier to grok than `find`, the commands syntax is a straight up improvement, it comes with sane defaults which makes the easy things and common usecases simple, while the harder ones are way more accessible. It uses colored output in an actually useful way, its manpage is more structured and easier to read...

and MOST IMPORTANTLY

...it is capable of running commands on search results with parallel execution out of the box, so no need to get GNU parallel into the command.

THIS is the kind of renewal of classic command line utilitis we need!

Literally the only pain point for me, is that it doesn't use glob-patterns by default, and that is easily fixed by a handy

    alias gf="fd -g"

Haven't found a way to use these tools in a user-local way.

For my own homemade tools, i put the binary in my dotfiles and they end up in .local/bin and i can use them by default. I can do that because I don't need to update them.

I like `fd -o {user}` and `fd --newer {time}` to find recently changed files and owned by others.

This is a VERY fast file searching tool. It's crazy good.

[0] https://www.hackerneue.com/item?id=31489004

I use fd all the time.

Simply having a better command line interface is a big deal.

    alias fd="rg --files | rg"

    $ touch $'a.\xFF'
    $ find -name $'*.\xFF'
    ./a.?
    $ ./fd -e $'\xFF'
    error: invalid UTF-8 was detected in one or more arguments

    Usage: fd [OPTIONS] [pattern] [path]...

    For more information, try '--help'.
    $
    $ touch III
    $ LC_ALL=tr_TR.UTF-8 find -iname 'iii'
    $ LC_ALL=tr_TR.UTF-8 ./fd 'iii'
    III
    $

The original problem that led me to thinking about this, was that I wanted to do a search that would include all files below the current directory, except if they were within a specific subdirectory.

(Why not just `grep -v` for that directory? Because the subdir contained millions of files — in part, I was trying to avoid the time it would take find(1) just to do all the system calls required to list the directory!)

And yes, this is possible to specify in find(1). But no, it's not ergonomic:

    find . -path ./excluded_dir -prune -o -type f -print

    find . \( -path ./excluded_dir -prune \) -o \( -type f -print \)

But this makes "what find(1) does under the covers" very clear: it's assembling your expression into a little program that it executes in the context of each dirent it encounters on its depth-first traversal. This program has filtering instructions, like `-path`, and side-effect instructions, like `-print`. You can chain as many of each as you like, and nest them arbitrarily within (implicit or explicit) logical operators.

After some further experimentation, I learned that find's programs are expression-based; that every expression implicitly evaluates to either true or false; and that any false return-value anywhere in a sub-expression, is short-circuiting for the rest of that sub-expression. (You could think of every instruction as being chained together with an implicit &&.) This means that this won't print anything:

    find . -false -print

    find . -path ./excluded_dir -prune -o -type f -print

    (path("./excluded_dir") && prune()) || (type("f") && print())

    find '(or (and (path "./excluded_dir") prune) (and (type f) print))'

But it's pretty easy to work around this need — just push both of these concerns "to the edge" (i.e. outside the expression itself. Like SQL statement binding!)

• Support $VAR syntax for plain references to exported env-vars.

• Support positional binding syntax (?1 ?2 ?3) for positional arguments passed after the script.

• Support named binding syntax (?foo) for positional arguments after the script that match the pattern of a variable-assignment (ala make(1) arguments):

    find '(or (and (path ?excluded_dir) prune) (and (type f) (iname ?1) print))' foo excluded_dir="${bar[1]}"