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.
» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10
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:
Show running time. eta, progressbar
Create an image of "device" and send it to another machine through the network ("target" and "port" sets the ip and port the stream will be sent to), outputting a progress bar
On the machine that will receive, compress and store the file, use:
nc -l -p <port> | 7z a <filename> -si -m0=lzma2 -mx=9 -ms=on
Optionally, add the -v4g switch at the end of the line in order to split the file every 4 gigabytes (or set another size: accepted suffixes are k, m and g).
The file will be compressed using 7z format, lzma2 algorithm, with maximum compression level and solid file activated.
The compression stage will be executed on the machine which will store the image. It was planned this way because the processor on that machine was faster, and being on a gigabit network, transfering the uncompressed image wasn't much of a problem.
Only slightly different than previous commands. The benefit is that your "watch" should die when the dd command has completed. (Of course this would depend on /proc being available)
Assuming we have a disk image, created by dd if=/dev/sda of=image.dd we can check the image's partition layout with fdisk -ul image.dd, then substitute "x" with starting sector of the partition we want to mount. This example assumes that the disk uses 512Byte sectors
the speed is about 500MB/s on my machine.
i think it's fast enough to output not too many bytes.
while a C program may output 1GB per sencond on my machine.
if the size is not the power of 512,you may change the bs and count in dd.
Step#2 Create a copy of the bootload and partition table!
Adjust "sleep X" to your needs.
*NOTE: First sleep is required because bash doesn't have a "post-test" syntax (do XXX while).
In general, this is actually not better than the "scrot -d4" command I'm listing it as an alternative to, so please don't vote it down for that. I'm adding this command because xwd (X window dumper) comes with X11, so it is already installed on your machine, whereas scrot probably is not. I've found xwd handy on boxen that I don't want to (or am not allowed to) install packages on.
NOTE: The dd junk for renaming the file is completely optional. I just did that for fun and because it's interesting that xwd embeds the window title in its metadata. I probably should have just parsed the output from file(1) instead of cutting it out with dd(1), but this was more fun and less error prone.
NOTE2: Many programs don't know what to do with an xwd format image file. You can convert it to something normal using NetPBM's xwdtopnm(1) or ImageMagick's convert(1). For example, this would work: "xwd | convert fd:0 foo.jpg". Of course, if you have ImageMagick already installed, you'd probably use import(1) instead of xwd.
NOTE3: Xwd files can be viewed using the X Window UnDumper: "xwud <foo.xwd". ImageMagick and The GIMP can also read .xwd files. Strangely, eog(1) cannot.
NOTE4: The sleep is not strictly necessary, I put it in there so that one has time to raise the window above any others before clicking on it.
The above command will send 4GB of data from one host to the next over the network, without consuming any unnecessary disk on either the client nor the host. This is a quick and dirty way to benchmark network speed without wasting any time or disk space.
Of course, change the byte size and count as necessary.
This command also doesn't rely on any extra 3rd party utilities, as dd, ssh, cat, /dev/zero and /dev/null are installed on all major Unix-like operating systems.
dcfldd is a forensic version of dd that shows a process indicator by default.
The 'dd' command doesn't provide a progress when writing data. So, sending the "USR1" signal to the process will spit out its progress as it writes data. This command is superior to others on the site, as it doesn't require you to previously know the PID of the dd command.
"killall -USR1 dd" does not work in OS X for me. However, sending INFO instead of USR1 works.
every 1sec sends DD the USR1 signal which causes DD to print its progress.
This line removes the 300k header from a Nero image file converting it to ISO format
bs = buffer size (basically defined the size of a "unit" used by count and skip)
count = the number of buffers to copy (16m * 32 = 1/2 gig)
skip = (32 * 2) we are grabbing piece 3...which means 2 have already been written so skip (2 * count)
i will edit this later if i can to make this all more understandable
Requires the dc3dd package - available at http://dc3dd.sourceforge.net
This is a more accurate way to watch the progress of a dd process. The $DDPID=$! is needed so that you don't get the PID of the sleep. The sleep 1 is needed because in my testing at least, if you run kill -USR1 against dd too quickly, it will kill it off instead of display the status. So you need to wait a second, probably so that it can configure itself to trap the USR1 signal.