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 comes in handy if you have daemons/programs that have potential issues and stop/disappear, etc., can be run in cron to ensure that a program remains up no matter what. Be advised though, if a program did core out, you'd likely want to know why (gdb) so use with caution on production machines.
This is a 'killall' command equivalent where it is not available.
Prior to executing it, set the environment variable USERNAME to the username, whose processes you want to kill or replace the username with the $USERNAME on the command above.
Side effect: If any processes from other users, are running with a parameter of $USERNAME, they will be killed as well (assuming you are running this as root user)
[-9] in square brackets at the end of the command is optional and strongly suggested to be your last resort. I do not like to use it as the killed process leaves a lot of mess behind.
The trick here is to use the brackets [ ] around any one of the characters of the grep string. This uses the fact that [?] is a character class of one letter and will be removed when parsed by the shell. This is useful when you want to parse the output of grep or use the return value in an if-statement without having its own process causing it to erroneously return TRUE.
Useful to detect which process is causing system loads. It shows process PID so as we can take further actions.
This command is useful when you want to know what process is responsible for a certain GUI application and what command you need to issue to launch it in terminal.
while [ 1 -ne 6 ]; do
pid=`ps -ef | grep -v "grep" | grep "trans_gzdy" | cut -c10-17`
ps gv $pid | head -2
check changes of RSS.
Surround the first letter of what you are grepping with square brackets and you won't have to spawn a second instance of grep -v. You could also use an alias like this (albeit with sed):
alias psgrep='ps aux | grep $(echo $1 | sed "s/^\(.\)/[\1]/g")'
The description of how the one-liner works is here at my blog:
8~osstat, $2~pid, $11~cmd
Shows a tree view of parent to child processes in the output of ps (linux). Similar output can be achieved with pstree (also linux) or ptree (Solaris).
Probably posted previously, I use this all the time to find and kill a process for "APP". Simply replace "APP" with the name of the process you're looking to kill.
I like to make it an alias in my .bashrc file, as such:
alias psme='ps -ef | grep $USER'
Kill all processes with foo in them. Similar to pkill but more complete and also works when there is no pkill command.
Works on almost every Linux/Unix platform I have tried.
ps returns all running processes which are then sorted by the 4th field in numerical order and the top 10 are sent to STDOUT.