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:
With code, the only way to have spaces parsed correctly in any kind of portable way is to use ... but then long lines will not wrap. That's kinda important for low-res screens or smaller windows.
- if someone copies the text as displayed in any browser, they'll get properly formatted code in their clipboard, without wrapping
- it fails gracefully so that it looks at least reasonable in all browsers, even those that don't know CSS/JS and can't do colours (eg lynx, screen readers)
If anyone knows a way, that would make me happy. Until then, I am stuck with the above as the best I can do.
For example, in LiveJournal, something like this:
<div width="100%" style="(the code above)"><pre>Code goes here</pre>
... will look considerably better and more readable than the default
<blockquote><pre></pre></blockquote>. It's not perfect, of course.
If you have enough control to create your own css file, you should definitely do that instead.
This will extract the differing CSS entries of two files. I've left the initial character (plus or space) in output to show the real differing line, remove the initial character to get a working CSS file. The output CSS file is usable by either adding it in a below the to original.css, or by only using the output but adding @import url("original.css"); in the beginning.
This is very useful for converting Wordpress theme copies into real Wordpress child themes.
Could exclude common lines within entries too, I guess, but that might not be worth the complexity.
This searches through all CSS files in the current directory and sub-directories, matches the content between "url(...)", and prints a list of all the URLs. If you prefer to see the file the URL came from, remove the -h and --nogroup params.
Ever compress a file for the web by replacing all newline characters with nothing so it makes one nice big blob?
It is a great idea, however what about when you want to edit that file? ...Serious pain in the butt.
I ran into this today in that my only copy of a CSS file was "compressed" with no newlines.
I whipped this up and it converted back into nice human readable CSS :-)
It could be nicer, but it does the job.