For Mac's, there are no parallel ports. However, if you're using a USB-serial adapter (which lets you use an STK500 or AVRISP v1 with a Mac) then you'll need to specify the serial port. I don't know a foolproof way yet but the way I do it is in the Terminal I type in ls -l /dev/cu.* and it will spit out a bunch of stuff (I screwed up the screen capture, this image has another window in front of it, but just ignore that)

/dev/cu.Bluetooth is the built in bluetooth stuff, dont use that. /dev/cu.modem is the modem (if there is one), dont use that either. What you're looking for is something like /dev/cu.usbserial or /dev/cu.KeySerial1 or something similar. In this case its /dev/cu.usbserial-FTCTYG5U

OK we're at the important part. This is where we actually get around to telling avrdude how to put the data onto the chip. This command is rather complex, but we'll break it down.
<memtype> - can be flash, eeprom, hfuse (high fuse), lfuse (low fuse), or efuse (extended fuse)
r|w|v - can be r (read), w (write), v (verify)
<filename> - the input (writing or verifying) or output file (reading)
[:format] - optional, the format of the file. You can leave this off for writing, but for reading use i for Intel Hex (the prevailing standard )
Free
For example:
OK enough of this jibber-jabber. Its time to program the firmware into a chip!
Get your AVR target board ready to go, we'll be using an attiny2313 in this example but of course you should substitute the chip you're using (in which case the code will probably not do anything). Make sure the device is powered, either by batteries or a wall plug or by the programmer if the programmer can do it.
Download the test_leds.hex file and place it in C: (Windows) or your home directory (Mac)
Figure out what programmer you are using and which port its connected to (in this example I'll be using a usbtinyisp but anything is fine.) Since the usbtinyisp is a USB programmer I can leave off the -P <port> switch.
type in avrdude -c usbtiny -p attiny2313 -U flash:w:test_leds.hex
Avrdude should go through the following steps:
  1. Initializing the programmer (you wont see this if it works)
  2. Initializing the AVR device and making sure its ready for instructions
  3. Reading the device signature (0x1e910a) which confirms that the chip you specified in the command line (attiny2313) is in fact the chip that the programmer is connected to
  4. Erasing the chip
  5. Reading the file and verifying its a valid file
  6. Writing the flash
  7. Verifying the flash
Fuse memory is a seperate chunk of flash that is not written to when you update the firmware. Instead, the 3fuses tend to be set once (altho they can be set as many times as you'd like). The fuses define things like the clock speed, crystal type, whether JTAG is enabled, what the brownout (minimum voltage) level is, etc. For more information on fuses you can read about 'em here.
First you'll want to calculate fuses using the very convenient AVR Fuse Calculator
To program the fuses, use:
avrdude -c usbtiny -p attiny2313 -U lfuse:w:<0xHH>:m
avrdude -c usbtiny -p attiny2313 -U hfuse:w:<0xHH>:m
avrdude -c usbtiny -p attiny2313 -U efuse:w:<0xHH>:m
Where <0xHH> is the desired fuse value, in hex. For example to set the high fuse to 0xDA:
avrdude -c usbtiny -p attiny2313 -U hfuse:w:0xDA:m
Setting the fuses incorrectly can 'brick' the chip - for example you can disable future programming, or make it so the chip is expecting an external crystal when there isn't one. For that reason I suggest triple-checking the fuse values. Then check again, make sure you aren't disabling ISP programming or the Reset pin or setting the clock speed to 32kHz. Then verify again that you have the correct chip for calculation. Then finally you can try writing them to the chip!
Remember: once you set the fuses you do not have to set them again
Stuff that can go wrong: AVR initilization failed
If the programmer is not properly connected to the chip, you'll get the following message: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check

Don't use -F to override the check, even though it is suggested!

This means that the programmer couldn't talk to the chip. If you are using a 'simple' programmer such as a serial or parallel port bitbang programmer, it could mean the programmer is at fault. Otherwise, it usually means the programmer is OK but it couldnt find the chip.
Check that the chip is powered, plugged into the socket or programmer properly, the programming cables are plugged in correctly, the header is wired correctly, etc. 99% of the time, it is a problem with wiring.
Just for kicks try running this command avrdude -c usbtiny -p atmega8 -U flash:w:test_leds.hex
You'll see that it stops at step 2, once the signature is different than the expected one it stops. This is because code that is compiled for an attiny2313 wont run on an atmega8 (this is true of most microcontrollers, the .hex files are not cross compatible)