Bat v0.26.0 (opens in new tab)

Libraries make sense when the tool is limited by the text-only Unix philosophy. E.g. highly concurrent or just high performance HTTP requests will be limited by the overhead of spawning `curl` processes, parsing responses, and having to re-allocate memory since you can't just take over the memory curl already allocated. Also when the user is unlikely to care which one you use (I don't care much what HTTP library a given binary uses).

Pagers are practically the worst thing to make this argument about, because they mesh perfectly with the strings-only nature of Unix. They take a string and allow the user to navigate through it. They only need to be fast at human-recognizable speeds, there's little reason for them to be highly concurrent, and there's a lot of value in allowing the user to choose which pager they want they to use.

More broadly, there's also value in composable tools because users can use the one they're familiar with. I can learn how jq works and use it with anything that outputs JSON, rather than having to learn the syntax of 18 different libraries various app developers have chosen for querying JSON. I can pipe whatever I want into 'more' instead of having to learn the keybinds for each of the 5 popular paging libraries.

It's not perfect, but I do think it's better than the embedded alternative for a lot of things.

Bloat cannot mean large contributor to the code size, since it's a tiny portion of the binary and dwarfed by the regex, syntax highlighter, and (sigh) command-line parsing. It also cannot mean unwanted feature, since every single time I have ever used it to look at a file I have wanted it paged, and I can't think of a circumstance where I wouldn't want it paged (given that my terminal is already set up to work with pagers, and otherwise I'd be well acquainted with configuring things not to be paged). So I wonder what it could mean in this context. (Myself I am fond of not wasting the same twenty seconds over and over again typing bonus things.)

The `less` command can toggle line numbers (`-N`, either as a command line argument, or while running it interactively) and toggle line wrapping (`-S`, again either way). It can also receive streamed output with `+F`, making it a viable alternative to `tail -f`. (I'm not sure if what you meant by static output is that it all has to be available before the command can read it.)

It can't adjust the columns in a table, but then I don't believe that `bat` can either, and I'm not aware of any similar program that can. (If there is one, please let me know.)

In the case of `bat` (or `man` or other programs that use a pager) it often requires no extra typing either, since `bat` will pipe it's output to `less` by default (or whatever you specify with the `PAGER` environment variable).

The `less` command can be quite a bit more powerful than it initially looks. I'd recommend looking over the man page sometime -- you might be surprised. In fact, looking over the `minus` page, other than being able to be compiled into another program so it doesn't have to be shipped separately on Windows, I'm not sure what it can do that `less` cannot. (If I'm missing some killer feature, please let me know. I'm not trying to bash `minus`, I just don't know what more it offers.)

I think practical Unix philosophy is more nuanced. There are filter programs that read STDIN and write to STDOUT per default.

But this is not really practical for many use cases which are not filters first and foremost. So we end up with still reading from STDIN or the list of files presented as arguments. We write to the file given by -o (or --output) which can be "-" to signify STDOUT.

I find this pattern very flexible because it allows multiple input files or STDIN and a single output file which can be STOUT, so you still get your filtering behaviour if you want.

(For completeness sake, there is a third pattern somewhat prevalent. In call these copy type programs. They treat the last argument specially, usually as some form of target, like `cp a b c target`.)

From my experience, --output is a minority in my workflow. Which tools do you use need --output?

Becky was so good for participating in mailing lists. I could slip by as a Unix user even though I was still mostly using Windows as my client OS.

I’m in the same boat with a lot of these tools, but bat is different in that it’s compatible enough to be safe to alias to the command it's replacing[1]. You can continue to use cat as usual, with the benefit of getting syntax-highlighted output.

[1]: Assuming you use the `--paging=never` flag in your alias as the README suggests.

brew usually manages to install these tools for me with no problems. And on the memory point, there's always `alias` or adding a symlink in ~/.local/bin. But, yeah, I have the exact same problem remembering to use `eza`. For some reason, I don't find `bat` as much of a problem; ls is probably more ingrained.

Just alias them in your shell config. You don't have to remember to use them if you have more and less just be aliases to bat. Same thing I do with eza, the ls replacement -- "ls" calls eza.

     alias bat='rview'

rview from vim, OFC.

Problem solved, you don't overwrite the files, you get all the vim options and a much better syntax highlighting.

Oh, and, as a plus, you gain xxd, which can be useful in tons of contexts.

Along with bat, these are my main ones that I install always:

fd, a better find: https://github.com/sharkdp/fd

ripgrep (rg) a modern grep: https://github.com/BurntSushi/ripgrep

eza for ls replacement: https://github.com/eza-community/eza

duf is a cleaner df: https://github.com/muesli/duf

dust for du: https://github.com/bootandy/dust

Also fish + starship + yazi + helix, all of which mostly work perfectly with the defaults

Just a nitpick. The real use of cat is to concatenate two or more files and dump the result in its stdout. But people use it more like file viewer these days.

Bat is a file viewer in every sense. I have concatenated multiple files using bat. It does come in handy sometimes. But even the concatenated output is designed to be a visual aid, not the traditional concatenation that cat does.

It doesn't do that actually. It concatenates files. From the description on the man page:

    Concatenate FILE(s) to standard output.

    With no FILE, or when FILE is -, read standard input

https://man7.org/linux/man-pages/man1/cat.1.html

Nit-pick: It’s short for catenate (: