- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Image Open"/"Image View" does not work with special character in filename #4377
Comments
After reading the text, I would like to add that of course the file name (or the path) is meant when I wrote 'with a special character in it', not the content of the files (of course).
so: create an image file with the name "testö.jpg" or put an image file in a folder named "testö", MC won’t be able to open it with Enter or View the file info with F3.
It will work with an mp4 file, though (and call your video player of choice), so "testö.mp4" or a folder named "testö" will work. |
Works for me.
Please temporarily remove ~/.config/mc/mc.ext and try again. |
Removing mc.ext or even completely removing .config/mc: still the same (also if I use another account on the same computer).
I am not able to find a global mc.ext that might be used instead.
My locale is
I added debug code to the /usr/libexec/mc/ext.d/image.sh to see if it even gets called, which is not the case (I have since reverted back these changes, to make sure this isn’t the source of further issues)
Is there a way to print out the mc.ext which is currently in use? (i.e. the built-in one)?
One add: this is the same for jpg, gif and png files (I’m only writing this because in the current mc.ext (which I have since renamed), JPEG is the only one which adds one additional View command, the PNG, GIF, ... files directly refer to the Include=image part. |
Replying to ro-ee:
mc -F shows all directories used by mc.
Usually, global mc.ext is /etc/mc/mc.ext. There is no any built-in one. |
"type" key in mc.ext doesn't work properly with non-ascii file names because file utility replaces non-ascii characters in output to its octal codes and distorts a name. Midnight Commander then compares this name to supplied name (in ext.c:regex_check_type()) and calculates content_shift incorrectly, thus mc_search_new() fails. |
Thank you for the analyzing.
Replying to dimich:
Perhaps it depends on file version:
It's a good idea.
Cannot see any the useful info:
Perhaps it depends on file version too. |
I have file version 5.42
and get
notice that even the 'g' is missing in the filename.
Still, what I don’t understand that this does not happen with videos? or isn’t 'file' not invoked in all cases, and .mp4 files are detected by other means?
using the --raw/-r parameter on 'file' will print the correct character (or leave the character as-is), but it still gets shortened by one character:
|
From a bug report in opensuse forums, where I first reported this,
https://forums.opensuse.org/showthread.php/571604-(%E2%89%A5-0x80)?p=3137435#post3137435
it looks like a patch made to 'file' on May 28th is to blame. There is something wrong with the patch (even in -raw mde, because of the shortening of the file name), but I think going with the -b option is the better route to take. |
Replying to andrew_b:
Filename conversion was introduced recently by this commit: file/file@f448f3e and it is already in file-5.42.
Replying to ro-ee:
In default mc.ext videos are detected by filenames with "shell/regex" keys, not by "type". |
|
|
Merged to master: [ab63cd2].
|
|
Important
This issue was migrated from Trac:
ro-ee
(alexander@….it)image
,open
,view
,special characters
If I have an image file with either a special character (≥ U+0080) in it, for example German umlauts, or special punctuation (’, “, », …) in it, or in the path of it, it won’t be recognized as image, and pressing Enter (to open) or F3 to view won’t work.
"Image view" (F3) on the file then shows the hex view of the file instead of the image info usually displayed with images.
It works with video files though, so this seems limited to the image file detection.
The text was updated successfully, but these errors were encountered: