The length the widened password needs to be is determined by how well the web site stores it. Typically they will use a salted hash. They shouldn't, but you have no control over it. You tell pbkdf2 the length you require using --length. --length 10 (which means you have 80 bits of entropy) is a reasonable minimum. But that is 10 binary bytes and typically you can't enter binary into a password field. Pbkdf2 will encode it for you into something you can enter (see --charset). The length of the encoded version is determined by the encoding, with the default encoding needing 14 characters for an 10 byte widened password.
Pbkdf2 itself can be attacked using brute force. Its defense against this is the amount of time it takes to calculate the widened password. Ensuring that time is long enough is critical to the security of your "weak" password. It can be printed using --time. Experiment with --scrypt-iterations (or --pbkdf2-iterations if not using Scrypt) to set it to an appropriate value.
Pbkdf2 provides two algorithms for widening the password - a standardised one (PBKDF2) and a newer, stronger but less well tested one called Scrypt. The PBKDF2 algorithm extends the time by using many ALU (Arithmetic Logic Unit - a part of a CPU) operations. Nowadays there are devices with many more ALU's than a modern CPU (in some cases 1000's more) so this strategy is no longer as effective as it could and should be. The Scrypt algorithm extends the time by using many off-chip memory references. The difference between other devices and a modern CPU in accessing is much smaller - a factor of 10 is perhaps feasible with custom silicon.
However, this implies that to have any effect at all Scrypt must force the attacker to not use on-chip memory, because on-chip memory is very fast. Such on-chip memory is often called cache. Scrypt does this by using far more memory than can fit into the on-chip cache (at least double). Since you set the amount of memory Scrypt uses with the --scrypt option, the figure you supply is critical to protecting your "weak" password. Modern CPU's have very large on-chip caches, so the amount of cache found in a desktop class CPU is a good guide. Use at least twice that, more if you want the password to be secure for many years.
When choosing the strength of the "weak" password to use and how much time pbkdf2 should use to widen it, it is helpful to consider the resources that will be available to the person trying to break it - the attacker. These resources can be reduced to time and money. If you are prepared to wait a second for your password and the attacker is prepared to wait a week to crack it that means the attacker can test 604,800 passwords. 604,800 is roughly equal 2^19 which means they will crack any supplied "weak" password with 19 or less bits of entropy. If they are prepared to spend 1,000 times the amount of money you did on a CPU and are prepared to wait a week then it goes up to 30 bits entropy. Brute forcing a password with 40 bits of entropy is feasible for a very well funded and patient attacker. The price here means the price of the CPU chip, not the entire system. A desktop CPU chip has stabilized at around $100, the price of the system it is in is typically 10 times that - use the $100 figure. The price of a CPU in a phone or tablet is around $10.
In practice this means the "weak" password you supply should have an entropy of at least 40 bits. Estimating the entropy is more of an art form than a science. A conservative way of doing it published by the US government, It is called NIST Special Publication 800-63. As a guide NIST 800-63 says a password of 20 characters that has both upper case and non-alphabetic characters and avoid things easily associated with you (like names, places or dates) will be around 40 bits. You can trade entropy bits for time. In practice, this means for the inconvenience of remembering and typing each extra character you have after 20 you can halve the amount of time you have to wait for pbkdf2 to widen the password.
Pbkdf2 is useful for protecting data you care deeply about. Examples might be an encrypted file containing your bank account login details, a Bitcoin wallet containing a substantial sum, private gpg keys used to sign a code, or even a master password file. In every case this information will be stored in an encrypted file protected by a password. A suitable password needs at least 80 bits of entropy. Remembering and entering a password with 80 bits of entropy is not something even the most paranoid human will or even could do. This is the problem pbkdf2 is designed to solve.
Use the password output as the salt. (Yes, the password is a widened version of the supplied (very) weak password 'x'. However, you didn't supply a salt, so pbkdf2 generated a large random salt for you. The end result is a PDKBD2 hashed version of a salt no one has seen.)
The renamed version might be:
The entire file name becomes your salt.
P=$(pbkdf2 -s 256M -l 10 - passwords-B42iuHkFWKh9qe.txt) \
openssl aes-128-cbc -pass env:P -nosalt -e \
-in passwords-B42iuHkFWKh9qe.txt \
-out passwords-B42iuHkFWKh9qe.txt.aes
You will be prompted for your password. To decrypt, reverse this step by changing -e to -d and exchanging the filenames given to -in and -out.
Pbkdf's web page has a detailed explanation of the rational behind it's use. http://pbkdf2.sourceforge.net/
RFC 2898 for an explanation of PBKDF2. http://tools.ietf.org/html/rfc2898
Scrypt's home page is http://www.tarsnap.com/scrypt.html