[HN Gopher] Bat v0.26.0
       ___________________________________________________________________
        
       Bat v0.26.0
        
       Author : indentit
       Score  : 137 points
       Date   : 2025-10-20 06:49 UTC (16 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | hoistbypetard wrote:
       | When I saw this, I was hoping that [The
       | Bat!](https://www.ritlabs.com/en/products/thebat/) had been
       | released as FOSS. This is still pretty cool.
        
         | moepstar wrote:
         | Same, I thought they may have gone through a rebrand or
         | something..
         | 
         | I wonder how long ago it was I last used it - must've been
         | sometime around 2010 or a few years earlier..
        
         | rado wrote:
         | Came here to say exactly that. Loved it back in the day, great
         | app.
        
         | aquir wrote:
         | Same here...but this is cool stuff as well!
        
         | p0w3n3d wrote:
         | same. I believe I used to have some free version somewhere
         | (bought on a CD with a magazine)
        
         | tecleandor wrote:
         | OMG the flashback... I remember using "The Bat!" and Rimart's
         | "Becky! Internet Mail"
         | 
         | Exclamation marks seemed to be popular in names back in the day
         | :D
        
           | pilif wrote:
           | 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.
        
       | jansan wrote:
       | What is it? It says it is a cat clone, but what is cat?
        
         | trentearl wrote:
         | cat is a classic unix program that outputs the contents of one
         | or more files to stdout. It's short for concatenate
        
           | cpach wrote:
           | Nit-pick: It's short for catenate (:
        
         | AbuAssar wrote:
         | https://en.wikipedia.org/wiki/Cat_(Unix)
        
         | atoav wrote:
         | A very wide used command line program that prints out the
         | contents of a file on a terminal. Chances are pretty high cat
         | is installed on your system already.
         | 
         | Example: If you're navigating to the folder of a git repository
         | in your terminal and quickly want to see what the readme says
         | without having to open a file manager or going to the website
         | on github/gitlab/codeberg you can run:                 cat
         | README.md
         | 
         | Which shows the text stored in that file directly in your
         | terminal window.
         | 
         | bat does essentially the same, only fancier, with syntax
         | highlighting, some formatting and colors.
        
           | Flamingoat wrote:
           | 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
        
         | emil-lp wrote:
         | Bat is a _file viewer_ that supports syntax highlighting and
         | reads git status to also annotate added /deleted/changed lines.
         | 
         | The classic file viewer for a terminal is cat (or less).
        
           | goku12 wrote:
           | 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.
        
             | JohnKemeny wrote:
             | Just a nitpick. They said the classic file viewer is cat,
             | not that cat's primary purpose was viewing files.
        
             | chiffaa wrote:
             | To be 100% fair, Bat only acts this way when used in an
             | interactive environment. As far as I know, in non-
             | interactive cases (a la shell scripting) it falls back to
             | normal cat behaviour
        
               | goku12 wrote:
               | That's interesting! How did you know?
        
               | chiffaa wrote:
               | Their README claims the following
               | 
               | > 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 and fall back
               | to printing the plain file contents
               | 
               | which was good enough for me personally, but I also have
               | seen anecdotal evidence of people running `alias cat=bat`
               | with a bunch of your usual bash piping work without any
               | issues
        
       | Moosturm wrote:
       | I love "bat". It just give readability in the terminal a boost.
        
       | bargainbin wrote:
       | One of the first programs I install in any new setup. Just having
       | the line numbers in your snippets, when all your communication is
       | over asynchronous platforms with UX features designed by the
       | Greatest Minds at Microsoft, streamlines discussions do much.
        
         | signa11 wrote:
         | oh you cheeky cat ! w3c did a huge disservice by not including
         | the 'snarky' tag in their specification.
        
       | oneeyedpigeon wrote:
       | The `--pager=builtin` change is interesting; first time I've
       | heard of minus.
       | 
       | > Traditional pagers like more or less weren't made for
       | integrating into other applications. They were meant to be
       | standalone binaries that are executed directly by users. However
       | most applications don't adhere to this and exploit these pagers'
       | functionality by calling them as external programs and passing
       | the data through the standard input.
       | 
       | Do people widely agree with this? That sounds less like
       | 'exploitation' to me and more like 'the way Unix works'.
       | 
       | > This method worked for Unix and other Unix-like OSs like Linux
       | and MacOS because they already came with any of these pagers
       | installed. But it wasn't this easy on Windows; it required
       | shipping the pager binary along with the applications. Since
       | these programs were originally designed for Unix and Unix-like
       | OSs, distributing these binaries meant shipping an entire
       | environment like MinGW or Cygwin so that these can run properly
       | on Windows.
       | 
       | So, to support Windows, we have to:
       | 
       | - Abandon (maybe bypass) the core Unix principle of composing
       | programs to carry out more complex tasks - Reimplement a pager
       | library in every language
       | 
       | Is that really the best approach? Even if so, I would have
       | thought a minimal pager would be best, but the feature list of
       | this pager library is fairly extensive:
       | https://github.com/AMythicDev/minus?tab=readme-ov-file#featu...
        
         | bayindirh wrote:
         | > Do people widely agree with this? That sounds less like
         | 'exploitation' to me and more like 'the way Unix works'.
         | 
         | I personally don't. UNIX is made to be composable, and it's
         | composition. more, less, most all consider pipe input as first-
         | class citizens. I'm personally fond of "grep --color=always
         | file.ext | less --raw" to page colored output.
         | 
         | > Is that really the best approach?
         | 
         | I don't think so. If I was the developer, I'd embed the pager
         | only into the Windows build by default, and use system pagers
         | on other systems (by default). If any person/distro wants to
         | use the built-in pager, it'd be their choice.
         | 
         | I don't like when developers bloat their own code with good
         | intentions, but drift from their nice state to something
         | bloated.
        
           | pie_flavor wrote:
           | 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.)
        
             | bayindirh wrote:
             | Bloat is generally code complexity, which slows down
             | maintenance and development.
             | 
             | In this case, there's a new pager library, conditional
             | connections to the pager library, and possibly the whole
             | shebang of supporting both internal and external pagers at
             | the same time.
             | 
             | I seldom use bat, and I'm not hating it. Syntax
             | highlighting and line numbering looks nice for the use
             | cases I played with it, but I don't find chaining a couple
             | of pipes together to get something exactly I want, a waste
             | of time, esp. when mangling outputs of commands and taking
             | actions according to these outputs.
             | 
             | Development and system administration calls for different
             | conventions on the terminal, and I understand & respect how
             | developers like to "enhance" their terminals to work
             | faster. OTOH, after having both hats for a very long time,
             | I find most (if not all) of these "enhancements"
             | unnecessary because it's either distracting or getting in
             | the way.
             | 
             | For the most tiring and most-used expressions, I use
             | espanso to expand them on the terminal instantly, and I
             | found that doing this gives me more flexibility without it
             | being on my face.
             | 
             | Maybe this is because I can think further steps while
             | typing something in, and I don't waste that time in a sense
             | many people sees. Maybe we shouldn't strive to extract
             | efficiency over every nanosecond of work, and maybe there's
             | something happening we don't quite grasp in these moments
             | we label as "waste".
             | 
             | IDK.;)
        
         | dist-epoch wrote:
         | Most Unix CLI tools don't respect the unix philosophy anyway.
         | For example a lot support something like `--output file.txt`
         | when the Unix philosophy would say to not implement that and
         | just use `>> file.txt`
        
           | bayindirh wrote:
           | From my experience, --output is a minority in my workflow.
           | Which tools do you use need --output?
        
             | oneeyedpigeon wrote:
             | Coincidentally, I went looking for some the other day and
             | there were very few. Everything that uses --output for this
             | purpose, that I could find, was a compiler.
        
             | onestay42 wrote:
             | dd an company require if= and of=, if that counts
        
               | bayindirh wrote:
               | dd doesn't require either if= or of=. It'll read from
               | stdin (or pipe) if you omit if= and it'll write to stdout
               | happily if you omit of=.
               | 
               | From the man page:                   if=FILE - read from
               | FILE instead of stdin.         of=FILE -  write to FILE
               | instead of stdout.
               | 
               | So you can do:                  cat x.iso | dd
               | oflag=direct bs=4096kB | /dev/sdc
        
           | weinzierl wrote:
           | 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`.)
        
             | dist-epoch wrote:
             | --output was just one example. Many tools provide
             | formatting options, _ls_ can sort, _find_ can delete files
             | it finds, and so on.
        
               | bayindirh wrote:
               | I don't believe programs able to sort their output is
               | acting against the UNIX philosophy. "ls" lists files and
               | does a good job of it. find's -exec is a bit stretching
               | it (-delete came later IIRC), but generally it adheres
               | the philosophy pretty well.
               | 
               | From my experience of programming small utilities for
               | myself, UNIX philosophy says "a tool handles a single job
               | and handles it well" is a nod to fallacy of "gluing"
               | things together.
               | 
               | Because when you start to glue things beyond simple
               | pipes, the glue code becomes exponentially complex and
               | takes more and more of the program, which creates a
               | maintenance hell and affects performance (much more
               | profoundly on a PDP).
               | 
               | So, simple tools doing single things is both easier to
               | write and maintain, and they're much more performant in
               | general.
               | 
               | Remember the guy who left a whole Hadoop cluster in the
               | dust with GNU command line tools and some pipes, on a
               | small laptop.
        
         | indentit wrote:
         | Having to pipe to a pager - to follow the unix philosophy -
         | means: - extra typing each time - the pager receives static
         | output. There is no interactivity... Sure, most pagers can
         | search. But there is no way to have a table with adjustable
         | columns, or toggle word wrap or line numbers etc.
         | 
         | I feel that for a tool like bat, it is better to have it built-
         | in and not follow the composable philosophy because it is just
         | so much more convenient. Of course the minus integration in bat
         | is fairly basic at the moment, I guess supporting different
         | code paths for static pagers vs interactive would increase
         | maintenance burden quite a lot...
        
           | temp20251020 wrote:
           | 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.)
        
             | anthk wrote:
             | Your top comment it's what happens when shiny hipster
             | programmers refuse to read the less(1) documentation.
        
         | pie_flavor wrote:
         | Do One Thing*+++ And Do It Well[?]         * Parsing text
         | formats counts as zero things         + UX counts as two things
         | ++ APIs that do multiple operations that people might want to
         | split, with no individual APIs for the parts, count as doing
         | one thing          [?] Something that relies on cooperation
         | from every other process on the system but has no way to
         | enforce it counts as done well
         | 
         | Nobody bothers with this argument when the library is for,
         | like, HTTP clients, or PKZIP containers. Unix philosophy, like
         | most philosophy, exists mostly to be debated, and to be related
         | to the history of the world, rather than to be actually
         | implemented in the modern day.
        
           | everforward wrote:
           | 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.
        
         | rascul wrote:
         | Did Windows stop shipping a pager? 'type file | more' was a
         | thing on MS-DOS and Windows when I used them.
        
         | phlakaton wrote:
         | If you think of bat as in the same category of functionality as
         | a pager, I think it works.
         | 
         | Unlike cat, bat already seems deeply interested in the
         | presentation of text on a terminal. Pagination involves several
         | aspects of presentation of text on terminals. So, it's still
         | arguably one thing from a conceptual perspective.
         | 
         | Not knowing much about bat (so I don't know how much this has
         | already been thought of), I could even see bat and pager
         | integrating in a way that you couldn't easily as separate
         | programs. Supporting a feature where the opening lines of a
         | paragraph, or a new section, are deferred to the next page, for
         | example.
        
         | Narishma wrote:
         | Since when did Windows stop shipping a pager? IIRC it's been
         | there since DOS 2.0 from 1983.
        
       | sundarurfriend wrote:
       | bat is one of the few "new wave" tools that I install without
       | hesitation, with no worries about stability issues or silent
       | downsides. It has great defaults that make it feel like it always
       | does the right thing for the context, just an unambiguous
       | enhancement to my terminal experience.
        
         | jesucresta wrote:
         | any other recommendation?
        
           | theshrike79 wrote:
           | 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
        
             | fredoliveira wrote:
             | What is helix? Haven't heard of it before, I don't think.
        
               | Melonai wrote:
               | Helix is a Vim/Kakoune-inspired modal editor, with a
               | bunch of stuff built in by default. For example it has
               | support for a huge amount of LSPs and intergrates them
               | automatically.
               | 
               | It's command structure is also super similar to Vim's,
               | but, basically, "flipped" around. So you wouldn't write
               | "dw" to delete a word, but "wd". This means that you can
               | see whatever you're selecting to be deleted highlighted
               | before you actually execute the deletion. It has a bunch
               | of saner commands also for stuff people usually want to
               | do, like go to definition/usage, and honestly for people
               | who aren't Vim-addicts such as myself, it's probably a
               | good idea to check it out once, to see if it's a good fit
               | for you.
        
               | theshrike79 wrote:
               | I tried getting into nvim (handy for editing from the CLI
               | or over ssh), but within weeks the plugin system started
               | getting weird errors.
               | 
               | Then I tested Helix[0] when a friend suggested it and it
               | Just Works. Along with LSP support that just picks up
               | language servers automatically if you install them.
               | 
               | The target-action command style takes some getting used
               | to after (n)vim's action-target style, but I actually
               | prefer it now.
               | 
               | [0] https://helix-editor.com
        
               | DiabloD3 wrote:
               | fwiw, the plugin system doesn't magically just get "weird
               | errors", its always some form of user negligence.
        
               | theshrike79 wrote:
               | I literally didn't touch it and it started throwing
               | errors :)
        
             | AbuAssar wrote:
             | super useful list, you probably should expand it into a
             | blog post
        
             | ikety wrote:
             | I stopped using eza and lsd in favor of aliasing nushell's
             | ls command.
             | 
             | I guess it's not worth the entire dependency of nushell if
             | you don't see yourself ever dabbling with it in other ways
             | (you should it's sick).
             | 
             | Also I'd add to your list zoxide
             | 
             | I've aliased cat to bat, cd to zoxide, and ls to nushell ls
             | with zero issues.
        
               | ItsHarper wrote:
               | I've started writing all of my scripts in nushell (unless
               | It's critical that they keep working long-term without
               | maintenance). It's incredible, and improving fast.
        
             | sintax wrote:
             | "A breadth-first version of the UNIX find command" --
             | https://github.com/tavianator/bfs
        
             | jadbox wrote:
             | Zsh > fish for me. It's about script compatibility.
        
               | theshrike79 wrote:
               | All my scripts start with #!/bin/bash
               | 
               | Zero issues with compatibility
        
         | bboozzoo wrote:
         | I probably have a bunch of such tools installed on my main
         | machine. The problem is you actually need to remember to use
         | them, and then maybe their command line switches to get the
         | desired output. Whereas cat/less/git/vim are muscle memory. Not
         | to mention that you first need to get over the hum of
         | installing them in your system, likely needing to grab the
         | latest Go/Rust/Zig toolchain along the way.
         | 
         | So while I admire the engineering effort, I still find utility
         | of these tools limited.
        
           | oneeyedpigeon wrote:
           | 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.
        
           | Cyphus wrote:
           | 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.
        
           | jhbadger wrote:
           | 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.
        
         | jftuga wrote:
         | Agreed. I use this program all day, every day. Viewing a file
         | without it now is just painful. :-)
         | 
         | I have these aliases, which are useful when piping output to
         | them:                   alias bd='bat -p -l diff'         alias
         | bh='bat -p -l help'         alias bi='bat -p -l ini'
         | alias bj='bat -p -l json'         alias bl='bat -p -l log'
         | alias bm='bat -p -l man'         alias by='bat -p -l yml'
        
           | anthk wrote:
           | 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.
        
       | lproven wrote:
       | TIL: Bat != .bat != The Bat.
       | 
       | https://en.wikipedia.org/wiki/Batch_file
       | 
       | https://www.ritlabs.com/en/products/thebat/
       | 
       | Expanded...
       | 
       | I have 2 mental definitions of "bat" as a term in computing. Only
       | one can be interpreted as a standalone piece of software that has
       | a version number. And this isn't it.
        
       | foofoo12 wrote:
       | The guy's brilliant. Check out his other projects too:
       | https://github.com/sharkdp?tab=repositories
        
         | jftuga wrote:
         | Slightly better link that filters to only to "Sources" (no
         | forks) and also by number of Stars.
         | 
         | https://github.com/sharkdp?tab=repositories&q=&type=source&l...
        
       | pkilgore wrote:
       | bat is part of my extended posix "Must Installs", nicely
       | extensible, glad to see it get love.
        
       | ctippett wrote:
       | Has anyone had any luck compiling bat for WebAssembly? I tried
       | recently to get a version I could run on a-Shell[1] on iOS, but
       | ran into issues with some of its dependencies.
       | 
       | [1]: https://github.com/holzschu/a-shell
        
       ___________________________________________________________________
       (page generated 2025-10-20 23:02 UTC)