Hi,
I confirm this bug even in version 2.3. I'll try to fix it during next days.
As a workaround, execute the program as:
$ LANG=en_GB.utf8 lfm
The important part is the encoding after the dot: utf8.
Kind regards,
Iñigo Serna
On 2 December 2012 03:39, patrick295767 patrick295...@gmail.com wrote:
Package: lfm
Version: 2.2-1
Severity: important
r
-- System Information:
Debian Release: 6.0.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages lfm depends on:
ii python 2.6.6-3+squeeze6 interactive high-level
object-orie
ii python-support 1.0.10 automated rebuilding support
for P
lfm recommends no packages.
lfm suggests no packages.
File /usr/bin/lfm, line 27, in module
lfm_start(sys.argv)
File /usr/share/lfm/lfm/lfm.py, line 924, in lfm_start
path = curses.wrapper(main, prefs, paths1, paths2)
File /usr/lib/python2.6/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File /usr/share/lfm/lfm/lfm.py, line 845, in main
app.load_paths(paths1, paths2)
File /usr/share/lfm/lfm/lfm.py, line 90, in load_paths
self.lpane.load_tabs_with_paths(paths1)
File /usr/share/lfm/lfm/lfm.py, line 299, in load_tabs_with_paths
err = tab.init(utils.decode(path))
File /usr/share/lfm/lfm/lfm.py, line 795, in init
err = self.init_dir(path)
File /usr/share/lfm/lfm/lfm.py, line 612, in init_dir
self.nfiles, self.files = files.get_dir(path,
app.prefs.options['show_dotfiles'])
File /usr/share/lfm/lfm/files.py, line 252, in get_dir
if ask_convert_invalid_encoding_filename(newf):
File /usr/share/lfm/lfm/utils.py, line 1001, in
ask_convert_invalid_encoding_filename
'In file %s, convert' % filename)
File /usr/share/lfm/lfm/messages.py, line 326, in confirm
win.addstr(1, 2 , '%s?' % utils.encode(question))
File /usr/share/lfm/lfm/utils.py, line 976, in encode
return buf.encode(g_encoding)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 33: ordinal not in range(128)
maybe due to _Op??ration
that has some e with accents
sincerely,
-- no debconf information
--
Iñigo Serna
Katxijasotzaileak
