Hide

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.


If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/

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.

Hide

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:

Hide

News

2011-03-12 - Confoo 2011 presentation
Slides are available from the commandlinefu presentation at Confoo 2011: http://presentations.codeinthehole.com/confoo2011/
2011-01-04 - Moderation now required for new commands
To try and put and end to the spamming, new commands require moderation before they will appear on the site.
2010-12-27 - Apologies for not banning the trolls sooner
Have been away from the interwebs over Christmas. Will be more vigilant henceforth.
2010-09-24 - OAuth and pagination problems fixed
Apologies for the delay in getting Twitter's OAuth supported. Annoying pagination gremlin also fixed.
Hide

Tags

Hide

Functions

Fast, built-in pipe-based data sink

Terminal - Fast, built-in pipe-based data sink
<COMMAND> |:
2011-08-28 23:48:29
User: h3xx
25
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.

Alternatives

There are 2 alternatives - 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 164 weeks and 5 days ago
help :

:: :

Null command.

No effect; the command does nothing.

Exit Status:

Always succeeds.

Comment by h3xx 164 weeks and 5 days ago

That makes a pipe status error :

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

141 0

where >/dev/null makes no error

Comment by sputnick 164 weeks and 5 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

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

Comment by qiaomuf 164 weeks and 5 days 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.

Comment by kevingranade 164 weeks and 5 days 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

Comment by unixmonkey365 164 weeks and 4 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 164 weeks and 4 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 164 weeks and 4 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

foo

Comment by kynnjo 164 weeks and 4 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 164 weeks and 3 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.

Comment by unixmonkey365 164 weeks and 3 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 164 weeks and 3 days ago

Your point of view

You must be signed in to comment.

Related sites and podcasts