[oneeyedpigeon]

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...

[pie_flavor]

    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]

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.

[bayindirh]

> 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]

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]

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.;)

[indentit]

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]

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]

Your top comment it's what happens when shiny hipster programmers refuse to read the less(1) documentation.

[phlakaton]

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.

[rascul]

Did Windows stop shipping a pager? 'type file | more' was a thing on MS-DOS and Windows when I used them.

[dist-epoch]

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`

[weinzierl]

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]

--output was just one example. Many tools provide formatting options, ls can sort, find can delete files it finds, and so on.

[bayindirh]

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.

[bayindirh]

From my experience, --output is a minority in my workflow. Which tools do you use need --output?

[oneeyedpigeon]

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]

dd an company require if= and of=, if that counts

[bayindirh]

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

[Narishma]

Since when did Windows stop shipping a pager? IIRC it's been there since DOS 2.0 from 1983.