[vthriller]

What you're showing here is not concatenation, there are fancy borders between file chunks and whatnot. Unless you have very different, unconventional definition of concatenation.

In fact, you're at odds with bat's README:

> you can still use bat to concatenate files. Whenever bat detects a non-interactive terminal (i.e. when you pipe into another process or into a file), bat will act as a drop-in replacement for cat

> It's hard to imagine many people have the muscle memory for the combination of cat, head, and whatever else you need to add headers with the filename and file size, call out empty files, highlight the second line, show line numbers, do syntax formatting

Honestly, it's harder to imagine many people with need for most combinations of these features. I can see general audience who would happily use one feature at a time, and if someone is constantly doing obscure one-off file analysis, chances are bat is just never enough, they're going to write long pipelines with awk/perl or use vim macros anyway, so there are no time savings nor convenience from using bat. (Is it really that much more convenient to read syntax-highlighted heads with line numbers? And I can barely remember the last time when `head` that also shows file sizes could've been much more handy than `du * ; head *`.)

Also, good luck using all that bat muscle memory in docker containers or old-school fleet of remote servers.

> and wrap to the terminal width (head doesn't do this)

Terminals already wrap long lines just fine, they don't need help from anything. They can also re-wrap lines when window gets resized.

(edit: expanded quote, markup fix)

[em-bee]

when i am concatenating multiple files i generally don't need highlighting. that said, when i am reading multiple files with less, switching back and forth between them is rather cumbersome, and having them concatenated together is actually a benefit, because for example i can search over multiple files at once. so bat is not a better cat, but it's a better less.