[mc] User menu: pattern matching acts not as expected

[Jörg Thümmler]

Am 12.03.25 um 11:37 schrieb Yury V. Zaytsev:
> 
>> On 12. Mar 2025, at 11:29, Jörg Thümmler via mc <mc at lists.midnight-commander.org> wrote:
>>
>> Am 12.03.25 um 10:10 schrieb Yury V. Zaytsev via mc:
>>>> On 12. Mar 2025, at 09:48, Eugen Fabian Karban via mc <mc at lists.midnight-commander.org> wrote:
>>>> $ mc -V
>>>> GNU Midnight Commander 4.8.22
>>> This version is 6 years old, and the current version is 4.8.33. Can you reproduce it with the latest version?
>>>> case 4:
>>>> filename='file_without_spaces_utf8_nonlocal_chars_à_á_'
>>>> debug=Wahr: f [[:space:]]
>>>> result=works NOT as expected (WRONG)
>>> It's impossible to understand what you mean by "works as expected" and “works NOT as expected". You mean it matches when it shouldn’t match?
>>
>> seems it's not a problem of the spaces but of the "nonlocal" chars.
> 
> Can you reproduce this?
> 
>> It's possible, your "nonlocal" chars are replaced internally by "?" and this interpreted as a wildcard…
> 
> 
> How is this even possible? Did you check the code?

Not at all. It's just the only difference between case 3 and case 4 (if 
I'm understanding Eugen's descriptions...) and I often saw strings with 
"nonlocal" chars printed as a collection of "?"s by the shell... and 
both filenames (3 and 4) are _without_ spaces (if I'm interpreting the 
"works as expected | works NOT as expected" well)

I tried my old mc on one system (4.8.22 too) and *[[:space:]]* selects 
the file with "nonlocal" chars if I try, assume Eugen's renaming should 
work as well (although I didn't check, whether the regex interpretion 
works similar in both cases)

But being in an utf charset too I can't imagine why "à" or "á" shall be 
"nonlocal" here. Seems more likely there is some charset mismatch on 
Eugen's system, at least for the acting user. Maybe there are 
"invisible" chars in the name in his environment...

-- 
cu

jth