In the current situation, iterating over `self.data.keys()` is OK only when
the dictionary is not modified, as `self.data.keys()` is lazily generated,
at least in Python 3.
Unfortunately, as we intend to change the dictionary with the `--purge`
option, we get a runtime exception when iterating the loop.
This commit fixes it by making the generation of the list of keys occur only
once, so that the dictionary itself can be modified in the body of the loop.
Tested with both Python 2.7 and Python 3.3.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
`path` is decoded already (coming from `db`) and this caused the
following error:
Traceback (most recent call last):
File "/home/user/.autojump/bin/autojump", line 460, in <module>
if not shell_utility(): sys.exit(1)
File "/home/user/.autojump/bin/autojump", line 429, in shell_utility
results = find_matches(db, patterns, max_matches, False)
File "/home/user/.autojump/bin/autojump", line 374, in find_matches
if current_dir == decode(os.path.realpath(path)) :
File "/home/user/.autojump/bin/autojump", line 277, in decode
return text.decode(encoding, errors)
File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xb4' in
position 52: ordinal not in range(128)
This regression bug was introduced when adding the KEEP_SYMLINKS option. The
current_dir was always set to '.' which would never match any database entries.
This adds the argparse library [1] as autojump_argparse and imports it
via sys.path mangling in case argparse does not exist (Python 2.6 or
below without argparse installed).
This makes autojump effectively work with Python 2.6 again by default.
I have not verified license compatibility, but given the intention of
the (backport) project this is likely OK (it is licensed under the
Python license).
1: http://code.google.com/p/argparse/
Fixes issue #121.
Also added unit test coverage to check database initialization, saving, and
loading. Unit tests also revealed that migration code was not working properly
(starts database from scratch instead of copying existing entries over).
