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 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.
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.
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.
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
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.
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...
> 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.
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.
any other recommendation?
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.
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
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..
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.
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.
I love "bat". It just give readability in the terminal a boost.
What is it? It says it is a cat clone, but what is cat?
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
Just a nitpick. They said the classic file viewer is cat, not that cat's primary purpose was viewing files.
https://en.wikipedia.org/wiki/Cat_(Unix)
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.