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/
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.
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.
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:
This command is somewhat similar to 'nice', but constrains I/O usage rather than CPU usage. In particular, the '-c3' flag tells the OS to only allow the process to do I/O when nothing else is pending. This dramatically increases the responsiveness of the rest of the system if the process is doing heavy I/O.
There's also a '-p' flag, to set the priority of an already-running process.
The Linux /dev/full file simulates a "disk full" condition, and can be used to verify how a program handles this situation.
In particular, several programming language implementations do not print error diagnostics (nor exit with error status) when I/O errors like this occur, unless the programmer has taken additional steps. That is, simple code in these languages does not fail safely. In addition to Perl, C, C++, Tcl, and Lua (for some functions) also appear not to fail safely.
The backslash avoids any 'rm' alias that might be present and runs the 'rm' command in $PATH instead.
In a misguided attempt to be more "friendly", some Linux distributions (or sites/etc.) alias 'rm' to 'rm -i'. Unfortunately, this trains users to expect that files won't actually be deleted until they okay it. This expectation will fail with catastrophic results when they use other distributions, move to other sites, etc., and doesn't really even work 100% even with the alias. It's too late to fix 'rm', but '\rm' should work everywhere (under bash).
This is the setup I'm using for my largest project. It gives 357 lines per page (per side), which makes it fairly easy to carry around a significant amount of code on a few sheets of paper. Try it.
(I stick to the 80 column convention in my coding. For wider code, you'll have to adjust this.)
The date command does offset calculations nicely, handles concepts like "a month" as you'd expect, and is good for offsets of at least 100M years in either direction.
strace can be invaluable in trying to figure out what the heck some misbehaving program is doing. There are number of useful flags to limit and control its output, and to attach to already running programs. (See also 'ltrace'.)
This is priceless for discovering otherwise invisible characters in files. Like, for example, that stray Control-M at the end of the initial hash bang line in your script, which causes it to generate a mysterious error even though it looks fine.
('od' is the last word, of course, but for many purposes it's much harder to read.)
This is a quick and dirty way to generate a (non-floating-point) CPU-bound task to benchmark. Adjust "20" to higher or lower values, as needed. As a benchmark this is probably a little less bogus than bogomips, and it will run anywhere 'bc' does.
This command repeatedly gets the specified process' stack using pstack (which is an insanely clever and tiny wrapper for gdb) and displays it fullscreen. Since it updates every second, you rapidly get an idea of where your program is stuck or spending time.
The 'tac' is used to make the output grow down, which makes it less jumpy. If the output is too big for your screen, you can always leave the 'tac' off to see the inner calls. (Or, better yet--get a bigger screen.)
Caveats: Won't work with stripped binaries and probably not well with threads, but you don't want to strip your binaries or use threads anyway.