What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again.

Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.

Get involved!

You can sign-in using OpenID credentials, or register a traditional username and password.

First-time OpenID users will be automatically assigned a username which can be changed after signing in.

Universal configuration monitoring and system of record for IT.

Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.

» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10

Subscribe to the feeds.

Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):

Subscribe to the feed for:



May 19, 2015 - A Look At The New Commandlinefu
I've put together a short writeup on what kind of newness you can expect from the next iteration of clfu. Check it out here.
March 2, 2015 - New Management
I'm Jon, I'll be maintaining and improving clfu. Thanks to David for building such a great resource!

Top Tags



Psst. Open beta.

Wow, didn't really expect you to read this far down. The latest iteration of the site is in open beta. It's a gentle open beta-- not in prime-time just yet. It's being hosted over at UpGuard (link) and you are more than welcome to give it a shot. Couple things:

  • » The open beta is running a copy of the database that will not carry over to the final version. Don't post anything you don't mind losing.
  • » If you wish to use your user account, you will probably need to reset your password.
Your feedback is appreciated via the form on the beta page. Thanks! -Jon & CLFU Team

Fast, built-in pipe-based data sink

Terminal - Fast, built-in pipe-based data sink
2011-08-28 23:48:29
User: h3xx
Fast, built-in pipe-based data sink

This is shorter and actually much faster than >/dev/null (see sample output for timings)

Plus, it looks like a disappointed face emoticon.


There is 1 alternative - vote for the best!

Terminal - Alternatives
command >&-

Know a better way?

If you can do better, submit your command here.

What others think

I was curious where this was documented. In the Bash man page under "SHELL BUILTIN COMMANDS" : is the first built in command. Here is the description:

: [arguments]

No effect; the command does nothing beyond expanding arguments and performing any specified redirections. A zero exit code is returned.

Comment by nnutter 303 weeks and 6 days ago
help :

:: :

Null command.

No effect; the command does nothing.

Exit Status:

Always succeeds.

Comment by h3xx 303 weeks and 6 days ago

That makes a pipe status error :

ls |: ; echo ${PIPESTATUS[@]}

141 0

where >/dev/null makes no error

Comment by sputnick 303 weeks and 6 days ago

I tried it and it's much more slower than redirection:

time sh test.sh

real 0m0.342s

user 0m0.205s

sys 0m0.096s

time sh test1.sh

real 0m7.300s

user 0m0.266s

sys 0m1.912s


for i in `seq 1 100`


for j in `seq 1 100`


echo i >/dev/null




for i in `seq 1 100`


for j in `seq 1 100`


echo i|:



Comment by qiaomuf 303 weeks and 6 days ago


I reproduced your results, and the per-invocation overhead does seem to be higher, but I get this when applying the redirection to the script as a whole instead of invoking it from within the script:

time sh test/spew.sh > /dev/null

real 0m0.285s

user 0m0.148s

sys 0m0.136s

time sh test/spew.sh |:

real 0m0.008s

user 0m0.000s

sys 0m0.008s

cat spew3.sh

for i in `seq 1 100`


for j in `seq 1 100`


echo i



I think this is the usage the author intended, and it does seem to be much faster.

Comment by kevingranade 303 weeks and 6 days ago

try this:


now type in some letters. See how they get echoed to the screen. Now hit a newline. What happens?


now contrast this with:


which will soak up all kinds of control char except ^d

Comment by unixmonkey365 303 weeks and 6 days ago

This it not faster. In fact, just slower.

You are using a pipe thus calling fork and running inside a subshell where at the same time >dev/null just use a simple file redirection.

Comment by RanyAlbeg 303 weeks and 6 days ago
rany:~$ time >/dev/null real 0m0.000s user 0m0.000s sys 0m0.000s rany:~$ time :|: real 0m0.002s user 0m0.008s sys 0m0.000s rany:~$
Comment by RanyAlbeg 303 weeks and 6 days ago

Expanding on sputnick's point, this command is not a good idea, because it can cause the upstream code to terminate prematurely. In the example below, the inline perl script is supposed to create a new file foo after producing some output, but it fails to create the file if it is piped through :. (NB: that the amount of output sent to the screen needs to be sufficiently large to observe this effect. YMMV)

ls foo

ls: foo: No such file or directory

perl -e 'print 0 for 1..10000; open FOO, ">foo"' |: ls foo

ls: foo: No such file or directory

perl -e 'print 0 for 1..10000; open FOO, ">foo"' > /dev/null ls foo


Comment by kynnjo 303 weeks and 5 days ago
time for x in {1..1000} ; do cat /tmp/VAR.log >/dev/null ; done real 0m2.956s user 0m0.320s sys 0m0.790s time for x in {1..1000} ; do cat /tmp/VAR.log :| ; done -bash: syntax error near unexpected token `;'
Comment by unixmonkey365 303 weeks and 4 days ago


time for x in {1..1000} ; do cat /tmp/VAR.log |: ; done real 0m4.903s user 0m0.380s sys 0m1.480s

anyway, it seems to take longer for me. Shorter to type though.

Comment by unixmonkey365 303 weeks and 4 days ago

This command runs faster because there's a BROKEN PIPE!

In fact |: works that way:

- the : builtin is executed and its stdin is attached to the command stdout

- when the : execution finishes its stdin is closed, and so the stdout of command.

- this causes a BROKEN PIPE resulting in the error of $PIPESTATUS

Comment by ioggstream 303 weeks and 4 days ago

This is not the same as >/dev/null

It may seem faster because it actually makes the command to the left of the pipe to receive a SIGPIPE and die sooner (if it doesn't handle SIGPIPE somehow)


strace find / >/dev/null

and compare it to:

strace find / |:

and you'll see the difference.

Comment by ateijelo 80 weeks and 3 days ago

Your point of view

You must be signed in to comment.