cygwin “Bash Prompt Here” não funciona com umlauts

Question

Usando a entrada do menu de contexto do Windows Explorer "Bash prompt here" que é instalado com o pacote cygwin chere não funciona, quando o caminho contém um trema alemão em qualquer posição. Por exemplo: usá-lo para c:/temp/ö resulta em um prompt de Bash aberto em c:/temp , enquanto abrir um prompt cmd também funciona com umlauts no caminho.

Como resolvo esse problema?

FYI:

1. a entrada de registro criada é c:\opt\cygwin\bin\mintty.exe -e /bin/xhere /bin/bash.exe "%L" (no menu de contexto estendido "% L" é substituído por "% V"; mas isso também não funciona)
2. configuração de localidade no cygwin: LANG=de_DE.UTF-8
3. O sistema de arquivos é NTFS. Portanto, os nomes de arquivos são reivindicados para serem armazenados em "Unicode", o que isso significa na respectiva documentação ( Descrição do Windows Dev Center da codificação para nomes de arquivos )
4. Página de códigos na janela do CMD: 850 (de acordo com o comando do powershell [System.Text.Encoding]::Default )
5. Página de códigos do Windows: 1252
6. Todos os três programas (windows explorer, cmd.exe, bash in mintty) mostram o trema de forma consistente, apesar de diferentes codificações
7. A renomeação de arquivos não é possível, pois o problema surge principalmente em unidades de rede com pastas / arquivos que são a) referenciados por muitos links (simbólicos, bem como atalhos do Windows) eb) possuídos / compartilhados por vários usuários diferentes

Answer 1

Por fim, acabei recebendo ajuda do desenvolvedor da casa própria, que gentilmente me indicou a documentação apropriada (mintty-wiki: link ). De acordo com o que as entradas de menu de contexto criadas por chere não funcionam com caracteres não-ASCII em nomes de diretório.

O problema, no entanto, pode ser mitigado simplesmente fornecendo um parâmetro adicional ao comando mintty, que pode manipular a tarefa sem necessidade do script xhere. Assim, a entrada do menu de contexto pode ser trocada apenas por C:\cygwin64\bin\mintty.exe --dir "%1" /bin/bash . A respectiva entrada agora funciona bem.

    

Answer 2

Se a página de código na janela do CMD for 850, o caractere no nome do arquivo será um único byte que não é uma sequência válida do UTF-8. O sistema provavelmente exibiria um glifo desconhecido , mas não é realmente estranho, inesperado ou estranho que em vez disso não mostre nada.

A solução simples é ignorá-lo. A correção um pouco menos simples é atualizar seu sistema para Unicode em todos os lugares. Renomeie todos os arquivos para ter nomes Unicode apropriados e configure a janela CMD para também usar cp65001 (não uma pessoa do Windows, portanto não me pergunte como. Não tenho certeza se você também precisa alterar a página de código padrão do Windows).

    

Answer 3

Para evitar esse problema e qualquer coisa relacionada a ele.

Use apenas caracteres com códigos hexadecimais ...

2d, traço
30-39, números
41-5a, maiúscula A-Z
5f, sublinhar personagem
61-7a minúscula a-z

... da tabela abaixo em nomes de arquivos.

Qualquer outra coisa acabará por ser uma fonte de problemas, por ex. se você mover arquivos em torno de diferentes sistemas operacionais em algum momento (... em compartilhamentos de rede e discos portáteis).

--- 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:  ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ