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.
> 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.
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...
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`
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.
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'
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.
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.
oneeyedpigeon|4 months ago
> 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...
pie_flavor|4 months ago
bayindirh|4 months ago
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.
indentit|4 months ago
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...
phlakaton|4 months ago
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.
rascul|4 months ago
dist-epoch|4 months ago
unknown|4 months ago
[deleted]
Narishma|4 months ago
hoistbypetard|4 months ago
moepstar|4 months ago
I wonder how long ago it was I last used it - must’ve been sometime around 2010 or a few years earlier..
tecleandor|4 months ago
Exclamation marks seemed to be popular in names back in the day :D
aquir|4 months ago
p0w3n3d|4 months ago
rado|4 months ago
sundarurfriend|4 months ago
bboozzoo|4 months ago
So while I admire the engineering effort, I still find utility of these tools limited.
jftuga|4 months ago
I have these aliases, which are useful when piping output to them:
jampekka|4 months ago
Just tried it out yesterday and it by default output white text on my white background terminal. :(
jesucresta|4 months ago
bargainbin|4 months ago
signa11|4 months ago
foofoo12|4 months ago
jftuga|4 months ago
https://github.com/sharkdp?tab=repositories&q=&type=source&l...
Moosturm|4 months ago
kI3RO|4 months ago
it's useless without such a small thing.
edit: [n] G Go to the very bottom of the output. If n is present, goes to that line
Oh capital G. What an intuitive keyword source:https://docs.rs/minus/latest/minus/#standard-actions
ksynwa|4 months ago
ctippett|4 months ago
[1]: https://github.com/holzschu/a-shell
pkilgore|4 months ago
unknown|4 months ago
[deleted]
jansan|4 months ago
AbuAssar|4 months ago
emil-lp|4 months ago
The classic file viewer for a terminal is cat (or less).
atoav|4 months ago
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.
trentearl|4 months ago
lproven|4 months ago
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.