Fast, built-in pipe-based data sink

<COMMAND> |:
This is shorter and actually much faster than >/dev/null (see sample output for timings) Plus, it looks like a disappointed face emoticon.
Sample Output 
# with >/dev/null:
$ time dd if=/dev/zero bs=1K count=100000 >/dev/null

100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 0.0355178 s, 2.9 GB/s

real    0m0.037s
user    0m0.011s
sys     0m0.025s

# with |:
$ time dd if=/dev/zero bs=1K count=100000 |:

real    0m0.002s
user    0m0.000s
sys     0m0.002s

22
By: h3xx
2011-08-28 23:48:29
pipe redirecting output built-in data sink
13

1 Alternatives + Submit Alt

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.
nnutter · 751 weeks and 1 day ago
help : :: : Null command. No effect; the command does nothing. Exit Status: Always succeeds.
h3xx · 751 weeks and 1 day ago
That makes a pipe status error : ls |: ; echo ${PIPESTATUS[@]} 141 0 where >/dev/null makes no error
sputnick · 751 weeks and 1 day 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 test.sh: for i in `seq 1 100` do for j in `seq 1 100` do echo i >/dev/null done done test1.sh: for i in `seq 1 100` do for j in `seq 1 100` do echo i|: done done
qiaomuf · 751 weeks and 1 day ago
giaomuf, 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` do for j in `seq 1 100` do echo i done done I think this is the usage the author intended, and it does seem to be much faster.
kevingranade · 751 weeks and 1 day ago
try this: cat|: now type in some letters. See how they get echoed to the screen. Now hit a newline. What happens? . now contrast this with: cat>/dev/null which will soak up all kinds of control char except ^d
unixmonkey365 · 751 weeks and 1 day 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.
RanyAlbeg · 751 weeks 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:~$
RanyAlbeg · 751 weeks 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 foo
kynnjo · 751 weeks 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 `;'
unixmonkey365 · 750 weeks and 6 days ago
D'oh... 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.
unixmonkey365 · 750 weeks and 6 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
ioggstream · 750 weeks and 6 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) Try: strace find / >/dev/null and compare it to: strace find / |: and you'll see the difference.
ateijelo · 527 weeks and 4 days ago

What do you think?

Any thoughts on this command? Does it work on your machine? Can you do the same thing with only 14 characters?

You must be signed in to comment.

What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again. 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.

Share Your Commands

Similar Commands

A simple command to toggle mute with pulseaudio (sink 0)

Redirect bash built-in output to stdout

Monitor progress of a command

PulseAudio: set the volume via command line

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: