Why does SPACE sometimes not work with more (or less)

Question

Usually with |more I press space to get another screenful. But with some commands space just does nothing, and I need to actually keep doing SPACE-ENTER to scroll forward a screen at a time. Both more and less behave the same.

On this machine this command shows both behaviours:

php -i |more;tree -A |more

With PHP I need to press ENTER after each space; with tree I just press SPACE and it scrolls.

I've tried a few tricks, such as 2>&1 and using bash, but no luck, e.g.

bash -c "php -i 2>&1;tree -A" | more

Joining the commands like that means SPACE-ENTER is needed for the whole output. So I'm wondering if PHP is outputting some control character that upsets more?

I've tried another machine, over SSH, and php -i does not have this behaviour.

(I have LESS set to -FRX. However I've cleared that variable and the behaviour is the same.)

This is just a minor irritant, so I'm not going to start pulling the two systems apart looking for the difference... just wondered if it rang a bell with anyone.

---

**UPDATE (Nov 26 2014) **

Someone contacted me to say they can reproduce this with:

Ubuntu 10.04.4 LTS GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) PHP 5.3.2-1ubuntu4.21 with Suhosin-Patch (cli) (built: Sep 4 2013 19:13:13)

My current system is now Mint 17 (PHP 5.5.9-1ubuntu4.5) and I do not have this behaviour. It is also fine on Ubuntu 14.04.1 (over SSH).

I do have the problem on Ubuntu 11.10 (over SSH). PHP 5.3.6-13ubuntu3.10

It is fine on Ubuntu 12.10 (over SSH). PHP 5.4.6-1ubuntu1.4

So it looks like a bug that might've been fixed between Ubuntu 11.x and 12.x, or between php 5.3 and 5.4? (If no-one can come up with any more evidence, I'll post that as a self-answer in a few weeks time.)

Answer 1

The more and less pagers are run with their standard input connected to the output of the previous elements in the command pipe. They have to explicitly open the controlling TTY device in order to provide their paging UI. The controlling TTY is also the standard input of the first element of the pipeline.

If the command being paged is reading from the TTY and/or interfering with it (changing TTY settings), you get strange behaviors like this.

For a crazy "trip", try something like:

$ vi file | less

Here is how we can make less require Enter for something that is normally a hot key:

(echo foo; sleep 1; stty icanon; bar) | less

If you wait for bar to appear, and consequently less's prompt, then you won't be able to quit less by just typing q. You will have to type qEnter. The program has messed with the TTY by putting it into canonical input processing mode: line-at-a-time input, rather than character-at-a-time.

If you hit Ctrl-C quickly during the sleep 1, you will instantly get the : prompt from less and will be able to quit with q since the stty never had a chance to execute.

If the command being paged does something with the TTY immediately on startup, then there is a race condition: which one will mess with the TTY first: the less program (in order to set up character-at-a-time input) or the program being paged? This is why there is a sleep in the above test; to let less win the race.

It does sound as if php (either itself or something loaded and executed by php) might have been doing something funny with the TTY, and that was fixed.