A design issue with the way command arguments are parsed causes a series of obscure bugs and robustness problems. Following are three manifestations of this issue, which affects all recent versions of KeePass including Release Candidate 1:
1. A database path such as
(containing more than one consecutive embedded blank) is not correctly recognized, because the multiple blanks are interpreted as a single blank.
2. Any tokens not beginning with a recognized command arg keyword are silently appended to the database path. For example, the command arg sequence
database.kdb -pw:abc -keyfi1e:pwsafe.key
(note misspelling of "keyfi1e") causes the password to be correctly recognized (as expected) and the keyfile parameter to be NOT recognized (as expected). However, the database path is also incorrectly interpreted to be
Furthermore, this all happens without any indication of a command line error.
3. The following database path
is silently interpreted as database.kdb, a possibly-valid path, but not what was entered. The entered database path is actually invalid, because it contains invalid characters (quotes).
All these issues (and probably more) arise because of incorrect assumptions about the way Windows processes command line arguments before presenting them to the application program. The key incorrect assumption appears in the KeePass documentation, which says, "The database file location is passed as argument. ... It doesn't matter if you enclose the path in quotes (") or not."
Well, sometimes it does matter. Windows interprets the command line as a series of blank-delimited tokens, except that anything enclosed in quotes is interpreted as a literal string. Therefore, if a path with multiple consecutive embedded blanks is not enclosed in quotes, there is simply nothing the program can do to recover the information necessary to form the intended path, because Windows throws away this information before presenting the token sequence to the program. To fix bug #1, one should conform to standard Windows practice: Always enclose any path (or other logical token) containing embedded blanks in quotes, like this:
Once the documentation is changed to reflect standard Windows practice, and the code suitably adjusted to account for it (see below), Bug #2 should automatically disappear as well (except for the part about silently ignoring -keyfi1e:pwsafe.key. That's a tougher problem beyond the scope of this post.).
Did I mention that when Windows interprets anything enclosed in quotes as a literal string, it throws away the quotes? Furthermore, it even does this within tokens. Therefore, KeePass interprets
as a keyfile with path equal to what appears between the quotes (but NOT including the quotes). This is just what we want!
Bug #3 is caused by code fragments like
if(psFile->Left(1) == _T("\"")) ...
The boolean value is true only when one inputs a very unnatural string such as is shown in the bug description. To get rid of Bug #3, get rid of lines like this. In fact, to eliminate ALL of the above bugs, simply set *psFile = __argv and get rid of the dozen and a half lines after the "Ignore this parameter" comment.
Well, this is pretty interesting. What you're reading in the above post is not what I wrote!!! I had written stuff like this:
(with "_" here denoting a blank character), but the wonders of SourceForge fora silently transformed this into stuff like
In other words, SourceForge deletes all but one consecutive blank from my post! Hope you can divine what I really said. If this causes too much confusion, I'll repost with _ representing blank.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.