Command substitution strips trailing newlines, which is a problem that quoting alone cannot solve. No sensible user or developer would put a newline at the end of any file name, but a malicious or clueless one might since Unix filesystems allow it. Parameter substitution is not vulnerable to this issue, and there are other reasons to prefer it to command substitution. The currently accepted answer uses command substitution, while @Gilles' answer which uses parameter expansion is the correct one.
–
jw013Aug 15 '12 at 18:22

If this comes up often, you can define a function. For example, put this in your ~/.bashrc:

d () {
if ! [ -d "$1/." ]; then
set -- "${1%/*}"
fi
cd -- "$1"
}

With this definition, you can run d /path/to/directory to change to the specified directory, or d /path/to/file to change to the directory containing the specified file (i.e. /path/to).

For this particular command, you can remove the last word by editing the command: with default key bindings, from the end of the line, press Alt+B to move back to the previous word and Alt+D to erase the word on the right. On most terminals, from the end of the line, you can press EscBackspace to directly erase the word on the left.

If the path is a directory, ~/home/blah/subdir/.. designates the same directory as ~/home/blah.

In zsh, you can tack (:h) at the end of a path to strip off the file name and keep only the directory part. (It's h for “head”; t for “tail” retains only the file part.) You can use other history modifiers within (:…) after a path or glob.

The "$(cmd)" form recommended by Chris is safest, but this is easier to type and will usually work just as well:

$ cd `dirname ~/home/blah/file.zip`

The difference is that the backticks form can be confused by certain characters in the command it's expanding. For a simple command like the one you show, you can immediately tell that it's not going to be a problem. For a shell script that needs to accept arbitrary arguments, it's safer to use the double-quoted $() form.

There are two differences here: the presence of double quotes, and the backticks vs $(…). The double quotes protect special characters in the output of the command; it's often safe to leave them off on the command line (if you know you don't have any troublesome file names), but not in a script. The backticks have weird rules for quoting the command itself, but they're ok to use for a simple command with no tested ` or backtick; in scripts, you might as well forget they exist and stick to $(…)`.
–
GillesMay 28 '12 at 23:36