and rsync works fine for people too, I guess that's why nobody uses Dropbox

Dropbox and rsync do different things. It looks like this does essentially the same thing.

Assuming perfect memory and you never make typos they are exactly the same. For most installs. Or distros. Probably.

You don't need to memorize

alias bat='f(){ cat "$1" | highlight --force -O xterm256 | less -SRNI; }; f'

For all the other issues people have pointed out, this assumes you have `highlight` installed.

As opposed to having bat installed?

> Assuming perfect memory and you never make typos they are exactly the same.

You can make an alias.

> For most installs. Or distros. Probably.

Comparing https://repology.org/project/bat-cat/packages vs https://repology.org/project/highlight/packages appears to show them with approximately equal availability. (Unless you're trying some other point, in which case I don't follow.)

I don’t know if it still uses librsync but for a long time Dropbox was based directly upon it.

Whether this proves or disproves anything in re syntax highlighting utilities I leave as an exercise.

It's a reference to this:

https://news.ycombinator.com/item?id=8863

I know. But that doesn't make it accurate. And in broader strokes, I'm not fond of that thread/comment being used to pretend that all new and shiny things are better than what came before. Sometimes the new thing is barely more than a coat of paint on the existing thing.

I call cat when I need to pipe or copy something, and just bat if I wanna read it myself. I find this as a good compromise, I like how bat formats things.

Your solution would be ok with an alias as well, so thanks. Might try it just so I dont need yet another program lying around

You can still pipe bat output as it falls back to unformated output when it detects a non-interactive terminal. https://github.com/sharkdp/bat?tab=readme-ov-file#file-conca...

But it's not in rust.

I don't seem to have "highlight" on my system.

That's because it is in ports rather than in base. (-:

* https://freshports.org/textproc/highlight/

* https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/textproc/hi...

* http://ports.su/textproc/highlight

* https://ports.macports.org/port/highlight/

Why not just install `bat` at that point?

That has git integration, like bat does? That shows non-printable characters like bat does? That allows you to concatenate and page multiple files at once like bat does? That supports the --line-range option like bat does? You can pipe the output of tail -f through your alias?

I guess if all you did was read the headline of the post you could assume your alias does all the same things as bat.

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

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

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.

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

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)

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.

Is it any different to remembering all the flags you’ve just used in bat?

Either way, you’d probably rely on either a capable shell’s autocomplete, or shell aliases. Or both.

I’m not trying to dismiss the usefulness of bat, I use it myself. But there’s also a lot of times i don’t have the luxury of installing bat (eg servers, or when working in highly regulated industries where you can only install software from a predefined list of approved packages) and I and others manage just fine.

My point is that the UNIX command line is extremely composable and supports a great deal more than people assume it does. bat is nice but to don’t assume stuff can’t be done without it.

It's clearly a joke in the vein of being able to recreate Dropbox with an FTP account, curlftpfs, and SVN/CVS.

looks like you are right, but... I almost never used all of this features with bat. Maybe tail -f sometimes. Do you really need this in daily workflow?

I use the syntax highlighting of manpages, fd, ripgrep, and git pretty regularly.

I also use the fzf previewer with --range-limited pretty frequently.

You don't need cat:

  highlight --force -O xterm256 < whatever | less -SRNI

Sadly does not work on fish because the developers does not believe that users are intelligent enough to understand the obvious and intuitive outcome of flipping ">" (a valid operator in fish).

you don't need "<" either. highlight takes a filename as argument just like cat or bat

I actually never used highlight so that is ignorance on my part.

i tried that:

    cat .bashrc  | highlight --force -O xterm256 | less -SRNI

everything is green, except line numbers are black (which comes from less), but

    bat .bashrc

shows actual syntax highlighting.

so apparently, no, it doesn't work.

to be fair, this is how it works:

   cat .bashrc | highlight --syntax shellscript -O ansi | less -R

to avoid getting caught by the useless use of cat police, this does too:

   highlight --syntax shellscript -O ansi .bashrc | less -R

however, i have to tell it which syntax to use

but to its credit, highlight even has support for pike, which bat doesn't (yet) (fixed that for myself, at least)

so overall, bat wins.

oh, i feel stupid now, the reason bat worked and highlight didn't was because bat had access to the filename extension. if highlight is called with a filename argument it can detect the syntax too.

so really bat and hightlight are equal, and it's not just a useless use of cat, but using cat here actually breaks the syntax detection. and it does so in bat too, obviously.

so this means highlight almost wins because it has pike support already, whereas for bat i had to add it, except that it turns out that if highlight can't detect the syntax it produces nothing, and you need --force to fix that, and if it is given multiple files as arguments it writes the output to files too, which is practically never what i want so i need to fix that with --stdout.

bat it is.

Although I agree with other commenters that your command can't compare to all of bat's features, many of which I appreciate... thank you for sharing this tip, I didn't know about `highlight` and I can't install `bat` at work.

This will live in my .bashrc for a long time:

    cat() {
      if [[ -t 1 ]]; then
        command cat "$@" | highlight --force -O xterm256
      else
        # plain cat to pipe into other things
        command cat "$@"
      fi
    }

This... doesn't work? Everything just comes out green. It's not clear to me how 'highlight' could even possibly know what syntax it's supposed to be highlighting when processing stdin, unless it ingests the whole thing until EOF and then applies some kind of fuzzy logic. If you feed it a filename as an argument, it just checks the extension.

curious, how did you have highlight installed?

i'd change the third line:

    command highlight --stdout --force -O xterm256 "$@"