This is what ended up with:

#!/bin/sh

tmpfile=$(mktemp gpgverifyXXXXXX)
trap "rm -f $tmpfile" EXIT

gpg --status-fd 3 --verify "$@" 3> $tmpfile || exit 1
egrep -q '^\[GNUPG:] TRUST_(ULTIMATE|FULLY)' $tmpfile

This looks for the trust information that gpg outputs on --status-fd. The script exits with an error in the presence of an untrusted signature (or invalid/no signature):

$ sh checksig sample.sh.bad 
gpg: Signature made Mon 24 Jun 2013 11:42:58 AM EDT using RSA key ID DCD5C569
gpg: Good signature from "Test User <testuser@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6FCD 3CF0 8BBC AD50 662E  5070 E33E D53C DCD5 C569
$ echo $?
1

The script exits with no error in the presence of a valid, trusted signature:

$ sh checksig sample.sh.good
gpg: Signature made Mon 24 Jun 2013 11:38:49 AM EDT using RSA key ID 5C2864A8
gpg: Good signature from "Lars Kellogg-Stedman <...>"
$ echo $?
0

Update

While the original post below correctly explains why you might want to use separate encryption and signing keys, it does not do a great job answering the question of why you use subkeys instead of the primary key. The Debian Wiki provides a much more thorough answer.

To summarize, your primary key is your online identity, and your identity and reputation are built up by having other people vouch for that key being yours by signing it themselves. (You might think of it like being your Twitter handle, and your reputation being your Twitter followers, or you might object to that analogy, but I hope it gives you some sense of why you want to protect it.) So, since your primary key is super important and is built up over years, you want to protect it very much. In particular, you do not want to store it on a computer that might get stolen or hacked into; you want to keep your primary key off-line in a safe place.

This, of course, makes your primary key very inconvenient to use. So for day-to-day operations you want to use a key that is not such a big problem to replace if it gets compromised. This is why subkeys were invented.

A subkey is still a public/private key pair and is secure as long as only you have the private key. It is, cryptographically, just as secure as your primary key. The difference is that your reputation is only attached to it by your own signature, the signature from your private key. To use the Twitter analogy, the world trusts that you are your Twitter handle because all your followers say so (I know, it doesn't always really work that way, but analogies are hard!), and then with that trust established you can then much more easily convince the world you own your Instagram handle by just tweeting it and people will believe you because the tweet came from your account, which they trust.

You still want to keep your subkey safe, but now if it is compromised it is not the huge problem it would be if your primary key were compromised (or, in the analogy, someone hijacked your Twitter account). Now you can just revoke the subkey and issue a new one by signing a revocation certificate and a new subkey and posting them both on your public keyring (like tweeting "hey, my Instagram handle changed, don't use the old one, use this one instead"). This makes keeping your subkey on your laptop computer a more acceptable risk than keeping your primary key on it.

TL;DR Subkeys make key management much easier by separating the cryptographic functions of public keys from the trust and identity functions of (primary) public keys.

Original post

If you look into the details of the math of public-key encryption, you will discover that signing and decrypting are actually identical operations. Thus in a naïve implementation it is possible to trick somebody into decrypting a message by asking them to sign it.

Several things are done in practice to guard against this. The most obvious is that you never sign an actual message, instead you sign a secure hash of the message. Less obviously, but just to be extra safe, you use different keys for signing and encrypting. Also, keeping the encryption key separate allows you to keep the other arguably more important and definitely less frequently used keys off-line and more secure. That is the case with the keys you have inspected. By the way the flags mean:

• e = encrypt/decrypt (decrypt a message you received encrypted for you to read)
• s = sign (sign data. For example a file or to send signed e-mail)
• c = certify (sign another key, establishing a trust-relation)
• a = authentication (log in to SSH with a PGP key; this is relatively new usage)

Note that in all cases, "key", means a public & private key pair.

This should not be a problem for your friend if he has everything set up correctly, but setting up everything correctly can be more complex than it should be. So it may be that the best solution is for your friend to generate a new public-key that he uses for both signing and encrypting. Like I said, because the primary defense against attack is to only sign a cryptographically secure hash of a message, it is not a serious weakness to have such a key.