mc and utf-8 again but different
Rostislav Beneš
xbenes5 at fi.muni.cz
Thu Nov 22 16:47:09 UTC 2007
On Thu, 22 Nov 2007 14:43:21 +0100, Vladimir Nadvornik <nadvornik at suse.cz>
wrote:
> It seems that there is the same bug as in the old utf8 patches: move and
> copy should preserve the original broken sequences, i.e. it should be
> possible
> to copy a file with 8859 name even if mc is in utf-8 mode. Both versions
> of utf-8 patch replace the invalid utf-8 sequences with questionmarks in
> target file name.
Another place where I have been inspired by first utf-8 patch.
Move/copy/delete dialogs use re_match function, that does not work with
invalid utf-8 strings. So every incorrect sequences are replaced with
question mark before calling re_match. I have thought that is not possible
keep them. But solution seems to be quite simple.
str_fix_string does not affect size of string and re_match return relative
positions of matches in string. So re_match is called with fixed fnsource,
but following cycle uses original and possible invalid fnsource. It works
fine on simple source masks like "*". I think that only case, where could
be this useful.
I'm only not sure if question mark is the best replacement character in
this case.
I have made standalone fix-01-copymove.patch (attached) for testing. If it
solved this bug, I will added it directly in my utf-8 patches.
(trick: if you set #enc:utf8, you will see only valid file names)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-01-copymove.patch
Type: application/octet-stream
Size: 1808 bytes
Desc: not available
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20071122/8cad559a/attachment.obj>
More information about the mc-devel
mailing list