The code page change is persistent, and could affect other programs that run later in the same console.And that if they must, they should change it back when theyre done.
Cygwin Windows Is Searching For Mintty Missing Code Page ChangeCygwin Windows Is Searching For Mintty Missing Software That MakesIt would take too long to fully explain what Cygwin is, but basically, its a suite of software that makes it easy to compile and run many Unix programs on Windows. Cygwin-compiled programs work best when run from Mintty, or another terminal program designed for that purpose. So, if you mix Windows and Unix programs together, you shouldnt be surprised if it doesnt work perfectly. So, it would be impossible to use the Unicode console API in such a situation. If you want Unicode output, one thing you could do is write UTF-8, cross your fingers, and hope for the best. Your program will use the Unicode API when writing to a console, and UTF-8 otherwise. Assuming Minttys character set was set to UTF-8, as it ought to be, everything would work fine. Your shell environment (e.g. LANG environment variable) should also be set to UTF-8, but that is usually derived automatically from your terminals setting. No need for the hack of using a pipe, when it could use an actual virtual Windows console instead. And Cygwin started doing just that, as of version 3.1.0 (December 2019). A triangle graphic characer, which is in CP437, but is in the problematic region below codepoint 32. This is also what happens on an actual Windows console (command prompt). Something happens to it after it passes through cat, and before it shows up on the terminal. Thats why it took me a while to notice that something was wrong. Cygwin sees that the last program in the pipeline is a Cygwin program, so it assumes the output it produces uses the Unix-like encoding setting (maybe from the LANG environment variable), which is UTF-8. But the output is going to a virtual Windows console, and the consoles code page setting is CP437. So, somewhere, somehow, something is converting the presumed UTF-8 text printed by cat to CP437 as it is printed to the console. If so, there must be another layer of translation happening first, to convert from UTF-8 to UTF-16, before converting from UTF-16 to CP437. Why couldnt it convert to UTF-16 instead of to the OEM code page, and then use the Unicode API to print it to the virtual console with full Unicode support. To reduce possible confusion, we can set both the input the output code page settings. Our program may end before its output gets all the way through the pipe, and only then does Cygwin look at the consoles code page setting after weve already set it back.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |