Re: Removing ^X in paths

[Thomas Wolff <towo@towo.net>]

Am 03.02.2022 um 05:12 schrieb Dennis Heimbigner:
> I am using 64bit.
> And it has nothing to do misreading characters.
>
> The ^X is described in this document: 
> https://www.cygwin.com/cygwin-ug-net/using-specialnames.html,
>
> There you will see this text:
>
> "If you don't want or can't use UTF-8 as character set for
> whatever reason, you will nevertheless be able to access the
> file. How does that work? When Cygwin converts the filename from
> UTF-16 to your character set, it recognizes characters which
> can't be converted. If that occurs, Cygwin replaces the
> non-convertible character with a special character sequence. The
> sequence starts with an ASCII CAN character (hex code 0x18,
> equivalent Control-X), followed by the UTF-8 representation of
> the character. The result is a filename containing some ugly
> looking characters. While it doesn't look nice, it is nice,
> because Cygwin knows how to convert this filename back to
> UTF-16. The filename will be converted using your usual
> character set. However, when Cygwin recognizes an ASCII CAN
> character, it skips over the ASCII CAN and handles the following
> bytes as a UTF-8 character. Thus, the filename is symmetrically
> converted back to UTF-16 and you can access the file."
This supports a non-UTF-8 cygwin client side, e.g. when running 
LC_ALL=de_DE mintty and you have a Chinese character in a file name.

> There is no obvious good reason to continue this convention.
See above, there is good reason and no reason to drop it.

Thomas

>
> On 2/2/2022 7:23 PM, L A Walsh wrote:
>> On 2022/02/02 12:40, Dennis Heimbigner wrote:
>>> It appears that windows now supports the UTF-8 codepage.
>> It has since early 2000's.
>>> I light of this, it seems time to change cygwin so it no longer adds 
>>> those
>>> control-x (^X)  characters in e.g. path names.
>> ^x is ASCII.  Cygwin doesn't insert ^X characters in paths.
>>
>> Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' 
>> with 2 horizontal lines, (Fullwidth Yen Sign  U+FFE5)...if that's the 
>> case, some 8-bit font
>> displayed that sign instead of a backslash in non-unicode locals.
>>
>> Are you using a 32-bit or 64-bit version of Cygwin?  on what version 
>> of windows?
>>
>> If you still use a 32-bit version, you might need to move to a 64-bit 
>> version.
>> I know the 32-bit version sometimes had the problem because it supported
>> fewer fonts and fewer characters at the same time.
>>
>> You might check out your locale (if in english, try setting:
>> LC_CTYPE="en_US.UTF-8"
>> in your shell and also check that your used font has a backslash in the
>> 0x7f position.
>>
>> But in shell, ^x is usually a character to erase the whole line -- so 
>> it really
>> wouldn't do to have it in a PATH.
>>
>> Hope this helps, and sorry if this is completely off base.
>>
>> Linda
>>
>>>
>>
>
>