Bat v0.26.0(github.com) |
Bat v0.26.0(github.com) |
> 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 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
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.
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.
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...
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.)
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.
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 wonder how long ago it was I last used it - must’ve been sometime around 2010 or a few years earlier..
Exclamation marks seemed to be popular in names back in the day :D
https://github.com/sharkdp?tab=repositories&q=&type=source&l...
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
The classic file viewer for a terminal is cat (or less).
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.
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
bat does essentially the same, only fancier, with syntax highlighting, some formatting and colors.
Concatenate FILE(s) to standard output.
With no FILE, or when FILE is -, read standard input
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.
So while I admire the engineering effort, I still find utility of these tools limited.
[1]: Assuming you use the `--paging=never` flag in your alias as the README suggests.
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' alias bat='rview'
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.
Just tried it out yesterday and it by default output white text on my white background terminal. :(
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
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.;)
I have a Becky backup on a Iomega Zip disk I have to check one day :D
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.
> 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
From the man page:
if=FILE - read from FILE instead of stdin.
of=FILE - write to FILE instead of stdout.
cat x.iso | dd oflag=direct bs=4096kB | /dev/sdcCat in 99% of the usage cases is used on one file
It does have the effect of what you describe if one file is supplied and might be the most common use case. That doesn't make your description correct, at best it makes it incomplete.
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.
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.
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.
Zero issues with compatibility