43.4. Problems Piping to a Pager
If your window onto Unix (terminal, X window, communications program, whatever) doesn't have a way to show you the previous screenful, using a pager program like more , pg, or less (Section 12.3) can be mighty handy. But piping to a pager doesn't always work the way you want it to.
% grep "^set" */.cshrc | more
That wasn't a fair question because you can't tell what's wrong. The problem (it turns out) is that the files named barney/.cshrc, edie/.cshrc, and gail/.cshrc are read-protected (Section 50.2). But as the first part of Figure 43-1 shows, the error messages scroll off your screen and the pager doesn't stop them.
Figure 43-1. Standard error bypassing pipe, going through pipe
Unless your display is reallllly sloooowww, the error messages are lost, and you never know they were there, or the errors are jumbled up with the "good" grep output. That's because you've told the shell to send only the standard output of grep to the pager program. And grep writes its errors to the standard error (Section 36.15)! But both stdout and stderr go to the screen at once. The errors on stderr scroll away with the output from the pager. The pager can't count the lines of errors, so it outputs a complete screenful of stdout (the "good stuff"). If grep's standard output (from the files it could read) is at least a screenful, as it is here, there are too many lines to fit on the screen -- and some lines will scroll off.
% grep "^set" */.cshrc |& more $ grep "^set" */.cshrc 2>&1 | more
(The Z shell understands both.) The second part of Figure 43-1 shows how this works. Any time I pipe a command's output to a pager, I usually combine the stdout and stderr this way.
Copyright © 2003 O'Reilly & Associates. All rights reserved.