[hnlmorg]

Not the GP and I do like bat, but to answer your questions:

> That shows non-printable characters like bat does?

cat does actually support that via the flags with -v (you can also use -t and -e to view tab and line endings too)

> That allows you to concatenate and page multiple files at once like bat does?

cat is literally called “cat” because it’s intended purpose is concatenation.

It’s not a pager though the GPs example did pipe to less anyway.

> That supports the --line-range option like bat does?

‘tail’ and ‘head’ would be muscle memory to a lot of people and not that different in terms of number of keystrokes.

But I do take your point that it’s nice to have that built into your pager.

> You can pipe the output of tail -f through your alias?

I couldn’t see why not. tail -f isn’t doing anything weird with the fd.

———

I’m not arguing against using bat though. I have it aliased to cat on my own machines, so I clearly and would recommend bat. But I do think some people might be surprised how far you can get with coreutils if bat wasn’t available

[freddie_mercury]

>> That allows you to concatenate and page multiple files at once like bat does? >cat is literally called “cat” because it’s intended purpose is concatenation.

cat's behaviour and bat's behaviour is different, though.

  >cat a.txt b.txt                                                                                                                                                                                         
  It was a dark and stormy night.
  Once upon a time.

  >bat a.txt b.txt
  ───────┬──────────────────────────────────────────────────────
         │ File: a.txt
  ───────┼──────────────────────────────────────────────────────
     1   │ It was a dark and stormy night.
  ───────┴──────────────────────────────────────────────────────
  ───────┬──────────────────────────────────────────────────────
         │ File: b.txt
  ───────┼──────────────────────────────────────────────────────
     1   │ Once upon a time.
  ───────┴──────────────────────────────────────────────────────

This difference becomes more useful once we have a more meaningful example:

  >cat *.py
  (thousands of lines of output)

  >bat -r :5 -H 2 --style full *.py
  ───────┬──────────────────────────────────────────────────────
         │ File: __init__.py   <EMPTY>
         │ Size: 0 B
  ───────┴──────────────────────────────────────────────────────
  ───────┬──────────────────────────────────────────────────────
         │ File: editor.py
         │ Size: 2.4 KB
  ───────┼──────────────────────────────────────────────────────
     1   │ import collections
     2   │ import contextlib
     3   │ import glob
     4   │ import io
     5   │ import os.path
  ───────┴──────────────────────────────────────────────────────

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, and wrap to the terminal width (head doesn't do this).

[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.

[em-bee]

highlight is not part of coreutils either. at least not on fedora.

[hnlmorg]

Not in any OS. In fact I hadn’t even heard of it before yesterday. But I’ll be looking into it now I know.