cygwin "Bash Prompt Here" not working with umlauts

Question

Using the windows explorer context menu entry "Bash prompt here" that is installed with the cygwin package chere does not work, when the path contains a German umlaut in any position. E.g.: using it for c:/temp/ö results in a Bash prompt opened in c:/temp, while opening a cmd prompt works also with umlauts in the path.

How do I resolve this issue?

FYI:

1. created registry entry is c:\opt\cygwin\bin\mintty.exe -e /bin/xhere /bin/bash.exe "%L" (in extended context menu "%L" is replaced by "%V"; but this also does not work)
2. locale setting in cygwin: LANG=de_DE.UTF-8
3. File system is NTFS. Therefore file names are claimed to be stored in "Unicode", whatever this means in the respective documentation (Windows Dev Center description of encoding for file names)
4. Codepage in CMD-window: 850 (according to powershell command [System.Text.Encoding]::Default)
5. Windows codepage: 1252
6. All three programs (windows explorer, cmd.exe, bash in mintty) show the umlaut in consistent manner despite different encodings
7. Renaming files is not possible as the problem mainly arises on network drives with folders/files that are a) referred to by lots of links (symbolic as well as windows shortcuts) and b) owned/shared by multiple different users

Answer 1

If the code page in the CMD window is 850, then the character in the file name is a single byte which is not a valid UTF-8 sequence. The system could probably display an unknown glyph � but it's not really strange, unexpected, or odd that it instead displays nothing at all.

The simple fix is to ignore it. The slightly less simple fix is to upgrade your system to Unicode everywhere. Rename all files to have proper Unicode names and then set up the CMD window to also use cp65001 (not a Windows person so don't ask me how. I'm not sure if you also need to change the Windows default code page).

Answer 2

Finally I ended up getting help from the mintty developer himself, who kindly pointed me to proper documentation (mintty-wiki: https://github.com/mintty/mintty/wiki/Tips#creating-a-folder-context-menu-entry-for-mintty). According to that the context menu entries created by chere do NOT work with non-ASCII characters in directory names.

The issue however can be mitigated simply by providing an additional parameter to the mintty command, which can handle the task itself without any need for the xhere script. So the context menu entry can just be exchanged by C:\cygwin64\bin\mintty.exe --dir "%1" /bin/bash. The respective entry now works just fine.

Answer 3

To avoid this problem, and anything related to it.

Use only characters with hex codes ...

2d,         dash
30-39,   numbers
41-5a,   upper case A-Z
5f,          underline character
61-7a    lower case a-z

... from the table below in filenames.

Anything else will eventually be a source of trouble, e.g. if you move files around different OS'es at some time (... on network shares and portable disks).

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