cygwin "Bash Prompt Here" не работает с умлаутами

Question

Использование записи в контекстное меню Windows Explorer "Bash Prompt Here" , который установлен с Cygwin пакет chere не работает, если путь содержит немецкий умляут в любом положении. Например: использование его для c:/temp/ö приводит к открытию приглашения Bash в c:/temp , в то время как открытие приглашения cmd работает также с umlauts в пути.

Как мне решить эту проблему?

FYI:

1. созданная запись реестра: c:\opt\cygwin\bin\mintty.exe -e /bin/xhere /bin/bash.exe "%L" (в расширенном контекстном меню "% L" заменяется на "% V"; но это тоже не работает)
2. настройка локали в cygwin: LANG=de_DE.UTF-8
3. Файловая система NTFS. Поэтому, как утверждается, имена файлов хранятся в "Юникоде", что бы это ни значило в соответствующей документации (описание кодировки имен файлов в Центре разработки Windows)
4. Кодовая страница в CMD-окне: 850 (согласно команде powershell [System.Text.Encoding]::Default)
5. Кодовая страница Windows: 1252
6. Все три программы (windows explorer, cmd.exe, bash in mintty) показывают умлаут последовательно, несмотря на разные кодировки
7. Переименование файлов невозможно, так как проблема в основном возникает на сетевых дисках с папками / файлами, на которые а) ссылается множество ссылок (символьных, а также ярлыков окон) и б), которые принадлежат / разделяются несколькими разными пользователями

Answer 1

Чтобы избежать этой проблемы и всего, что с ней связано.

Используйте только символы с шестнадцатеричными кодами ...

2d, тире
30-39, цифры
41-5a, верхний регистр AZ
5f, подчеркивание
61-7а строчная аз

... из таблицы ниже в именах файлов.

Все остальное в конечном итоге станет источником проблем, например, если вы когда-нибудь переместите файлы между различными ОС (... на сетевых ресурсах и переносных дисках).

--- HEX/DEC-coded character table ---
ECMA-Latin1 ~ ISO 8859-1

       0 1 2 3 4 5 6 7 8 9 a b c d e f 
       - - - - - - - - - - - - - - - -
 2/2:    ! " # $ % & ' ( ) * + , - . /
 3/3:  0 1 2 3 4 5 6 7 8 9 : ;  ?
 4/4:  @ A B C D E F G H I J K L M N O
 5/5:  P Q R S T U V W X Y Z [ \ ] ^ _
 6/6:  ` a b c d e f g h i j k l m n o
 7/7:  p q r s t u v w x y z { | } ~ 
 8/8:  
 9/9:  
10/a:    ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® ¯
11/b:  ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
12/c:  À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
13/d:  Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
14/e:  à á â ã ä å æ ç è é ê ë ì í î ï
15/f:  ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

Answer 2

Если кодовая страница в окне CMD - 850, то символ в имени файла является одним байтом, который не является допустимой последовательностью UTF-8. Система, вероятно, может отображать неизвестный глиф, но это не очень странно, неожиданно или странно, что вместо этого она вообще ничего не отображает.

Простое решение состоит в том, чтобы игнорировать это. Чуть менее простое решение - обновить вашу систему до Unicode везде. Переименуйте все файлы, чтобы они имели правильные имена в Юникоде, а затем настройте в окне CMD также использование cp65001 (не для Windows, так что не спрашивайте меня, как). Я не уверен, что вам также нужно изменить кодовую страницу Windows по умолчанию).

Answer 3

Наконец -то я в конечном итоге получить помощь от самого mintty разработчика, который любезно указал мне надлежащей документации (mintty-вики: https://github.com/mintty/mintty/wiki/Tips#creating-a-folder-context-menu- вход для мяты). В соответствии с этим записи контекстного меню, созданные chere, НЕ работают с не-ASCII-символами в именах каталогов.

Однако эту проблему можно решить, просто добавив дополнительный параметр в команду mintty, которая может обрабатывать саму задачу без использования скрипта xhere. Таким образом, пункт контекстного меню может быть заменен на C:\cygwin64\bin\mintty.exe --dir "%1" /bin/bash . Соответствующая запись теперь работает просто отлично.