Hacker News Reader

Comment by ventana | Hacker News Reader

This is a common approach, CLI tools often use isatty [1] to check if the output fd is a TTY or not. Try running "git log" for example; if you have many commits, it will page through "less" or $PAGER only if it sees that you're on a real TTY; but if not, it will not. Try this:

  git log                     # PAGER undefined; uses less
  PAGER=/usr/bin/head git log # pages through head, you get 10 lines
  PAGER= git log              # PAGER is empty; does not page
  git log | cat               # output is not a TTY; does not page

(also, notice that git uses colors if the output is going to a terminal, and does not if not)

I don't think I was ever bothered by the automatic paging through "less".

[1]: https://man7.org/linux/man-pages/man3/isatty.3.html

View on HN

I'm bothered by it because whatever git command that I'm executing will put its output in a pager and when I quit the pager it's not there anymore. I want the output on the screen when I start typing the next command. Oh my God, this is such a frustrating pattern.

Then export PAGER= in your shell profile should help!

Unfortunately not all programs respect an empty PAGER vs an unset PAGER. It's more reliable to use PAGER=cat

This is indeed an annoying, but solvable, less default. You can eg use `export LESS="-XF"` to change behaviour.

It took me way too many years before I set this as a default in my profile files.

The funny thing is. I kept missing this detail every time I read through git. Feels like I was blind to the whole concept of it

That's useful, although I don't know if I will enable it for generally or specifically for git.

I had the same issue specifically with git, for the same reason. You can configure git to not use a pager by setting core.pager to an empty string.

`git config --global core.pager cat` will fix this.

Another example, which I find very annoying, is `systemctl status`; when the service has... either enough log lines or wide enough lines, idk, it will helpfully page them. So checking the status of a service randomly may or may not block your terminal. I cannot stress enough that I do not want to have to look at the screen and decide interactively whether or not I need to hit q before I can run another command.

It also annoys me very much, especially horizontally. Wrapped lines are much easier to copy, for example if you want to do a Web search.

Yeah no. If I wanted to use a pager, I'd use a pager.

I want the output visible on screen after I exit the pager. If I didn't want it on screen, I'd pipe it to a file and open that in a text editor. That will disappear when I close the file. As a bonus: I can then use grep without having to repeat whatever command I used.

Even more importantly: I want the command to behave identically regardless of whether its stdin or stdout is /dev/null or a terminal or a socket or a serial port or a pipe or anything else that it can read or write with. Try writing a script when the tools themselves change how they behave whether they're running in a script or in a terminal or elsewhere. It kinda sucks.

> Try writing a script when the tools themselves change how they behave whether they're running in a script or in a terminal

But we smart coders. We think everything. Remind me later.

You make a reasonable point so I don't want to oppose it but just to offer more tricks in case some of you don't know them:

_less_ has a nice "&" command that is like "/" (search) but that filters instead like grep.

You can also pipe to an external command from less

Right. IMO this is bad behavior. I have `pager=cat` in my git config to deal with it there and several other aliases (include --no-pager) for systemd related stuff that do it to.

Reply on news.ycombinator.com