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.
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:
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:
Configures screen to always display the clock in the last line (has to be configured only once).
After that you not only have got the possibility to detach sessions and run them in background, but also have got a nice clock permanently on your screen.
If you provide the option -t to the script command and redirect stderr into a file, the timing information on what is going on on the terminal, is also stored.
You can replay the session via the scriptreplay command, where you can also provide a speedup factor (see the man page for details).
Great for demonstration purposes ...
As an alternative to using an additional grep -v grep you can use a simple regular expression in the search pattern (first letter is something out of the single letter list ;-)) to drop the grep command itself.
Within /proc and /sys there are a lot of subdirectories, which carry pseudofiles with only one value as content. Instead of cat-ing all single files (which takes quite a time) or do a "cat *" (which makes it hard to find the filename/content relation), just grep recursively for . or use "grep . /blabla/*" (star instead of -r flag).
For better readability you might also want to pipe the output to "column -t -s : ".
Get the name of the parent command. This might be helpful, if you need to react on that information. E. g. a script called directly via ssh has got sshd as parent, manually invoked the parent process will probably be bash
If you are doing some tests which require reboots (e. g. startup skripts, kernel module parameters, ...), this is very time intensive, if you have got a hardware with a long pre-boot phase due to hardware checks.
At this time, kexec can help, which only restarts the kernel with all related stuff.
First the kernel to be started is loaded, then kexec -e jumps up to start it.
Is as hard as a reboot -f, but several times faster (e. g. 1 Minute instead of 12 on some servers here).
Instead of calculating the offset and providing an offset option to mount, let lomount do the job for you by just providing the partition number you would like to loop mount.
You got some results in two variables within your shell script and would like to find the differences? Changes in process lists, reworked file contents, ... . No need to write to temporary files. You can use all the diff parameters you'll need. Maybe anything like $ grep "^>"
is helpful afterwards.
Let dd use direct I/O to write directly to the disk without any caching. You'll encounter very different results with different block sizes (try with 1k, 4k, 1M, ... and appropriate count values).