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
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.
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.
> 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.
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.)
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".
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...
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.)
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.
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`
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`.)
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.
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.
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.
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.
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.
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.
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.
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'
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.
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.
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.
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.
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.
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.
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
> 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
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.
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.
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...
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.
> 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.
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.)
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.;)
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...
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.)
Your top comment it's what happens when shiny hipster programmers refuse to read the less(1) documentation.
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.
Did Windows stop shipping a pager? 'type file | more' was a thing on MS-DOS and Windows when I used them.
Since when did Windows stop shipping a pager? IIRC it's been there since DOS 2.0 from 1983.
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`
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`.)
--output was just one example. Many tools provide formatting options, ls can sort, find can delete files it finds, and so on.
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.
From my experience, --output is a minority in my workflow. Which tools do you use need --output?
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.
dd an company require if= and of=, if that counts
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:
So you can do: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.
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..
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
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.
Same here...but this is cool stuff as well!
same. I believe I used to have some free version somewhere (bought on a CD with a magazine)
Came here to say exactly that. Loved it back in the day, great app.
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.
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.
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.
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.
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.
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:
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.
any other recommendation?
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
"A breadth-first version of the UNIX find command" -- https://github.com/tavianator/bfs
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.
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.
Zsh > fish for me. It's about script compatibility.
All my scripts start with #!/bin/bash
Zero issues with compatibility
What is helix? Haven't heard of it before, I don't think.
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.
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
fwiw, the plugin system doesn't magically just get "weird errors", its always some form of user negligence.
I literally didn’t touch it and it started throwing errors :)
super useful list, you probably should expand it into a blog post
The builtin pager doesn't have an END shortcut...
it's useless without such a small thing.
The guy's brilliant. Check out his other projects too: https://github.com/sharkdp?tab=repositories
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...
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.
oh you cheeky cat ! w3c did a huge disservice by not including the ‘snarky’ tag in their specification.
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
I love "bat". It just give readability in the terminal a boost.
bat is part of my extended posix "Must Installs", nicely extensible, glad to see it get love.
What is it? It says it is a cat clone, but what is cat?
https://en.wikipedia.org/wiki/Cat_(Unix)
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).
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.
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
That's interesting! How did you know?
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
Just a nitpick. They said the classic file viewer is cat, not that cat's primary purpose was viewing files.
cat is a classic unix program that outputs the contents of one or more files to stdout. It's short for concatenate
Nit-pick: It’s short for catenate (:
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:
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.
It doesn't do that actually. It concatenates files. From the description on the man page:
https://man7.org/linux/man-pages/man1/cat.1.html[delayed]
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.