← Back to context

Comment by ventana

2 hours ago

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

7 comments

ventana

Reply
jpitz  2 hours ago

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.

  • simon-b  2 hours ago

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

yjftsjthsd-h  1 hour ago

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.

inetknght  2 hours ago

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.