Re: Removing ^X in paths

[Dennis Heimbigner <dmh@ucar.edu>]

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."

There is no obvious good reason to continue this convention.


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
>
>>
>