yes, please clear my terminal
We’ve all been there. You’ve been running some commands. You switch focus
away from your terminal. You come back. And your terminal is full of crap
you’re not interested in anymore. “Get this out of my sight”, you think.
clear
you type.
Problem solved. Blog post over. Oh but wait! This doesn’t solve all my woes.
There’s another time when the ghosts of a command past can muddy your view.
Say you’ve run some tests. There’s lots of output that you’ll need to scroll
back through in case of a failure. You find the failure. You make a fix. You
run the tests again. There’s another failure. So you scroll up, Ctrl A, [, PgUp
or however you do it. This second time it’s easy to miss where your most
recent test output starts and where the old one ends.
I found clear
doesn’t work for me this time. Running clear
, then scrolling
up, I see no gap between the previous output and my prompt. Looking into the
man pages, it says “clears
your screen if this is possible, including its scrollback buffer (if the
extended “E3” capability is defined).”. OK so this is probably a tmux
issue.
Exiting tmux
I find that clear
does in fact clear the scroll history too.
Outside of tmux
, passing the -x
parameter to clear
(to stop it clearing
scrollback buffer) give me the same effect as I saw in tmux
.
So at this point I should probably give up on this blog post and go and work
out how to make clear
work the same in tmux
. But wait, there might still
be a use case that clear
can’t fulfil here. Suppose I want to not throw away
the old test output, but still have a clear point in the history where the old
test output ended and a new one begins.
You could solve this problem by holding down the return
key for a few seconds
so there was an obvious band in the terminal history of just the prompt. But
there’s a slightly more inventive solution:
yes "" | head -50
What’s going on here? yes
is a
command that will repeatedly
output the string given (or y
if no string is given). So giving it the empty
string will make it produce newlines to stdout.
The appearance of yes
in script or a command line is almost always a sign
that you’re doing something wrong. It can be used as a hack to automate
interactive CLIs that you know you’re going to say “yes” to:
yes | apt install foo
yes | rm -ir some_directory/
Or even if you know you’re going to say “no”:
yes no | <command>
I know, right.
But CLI commands usually have parameters that you can pass to achieve a non-interactive mode:
apt install -y foo
rm -rif some_directory/
It’s somewhat reminiscent of the “Useless Use of
cat
”.
Apart from my beautiful command above, I think I’ve only used yes
”legitimately” once: doing a quick test of a TCP connection by piping yes
into netcat… maybe. What is “legitimate usage” anyway…
head -50
will take the first 50 lines of this. The -50
parameter is
actually an undocumented
archaic use of head
(and tail
) which apparently is only supported for back
compatibility. It’s equivalent to -n 50
. You can change 50
with any
number. Some experimentation is needed with your terminal and the size of text
you have.
So there we have it. A slightly convoluted way of getting something you probably don’t need, but seems to have always amused anyone I’m paring with when I do it.
yes "" | head -50
I’m hoping someone chimes in with a “why don’t you just do X” so I can un-muscle-memory this one.