Re: [BUG REPORT] File names that contain UTF8 characters are unnecessarily escaped in 'git status .' messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-05-30 17:55, Yuri wrote:
> On 5/30/21 2:44 PM, Jeff King wrote:
>> Yeah, I'm not sure how such a check would be done. On most Linux systems
>> I've seen, $LANG will mention "en_US.UTF-8" or similar. But I've no idea
>> how portable that convention is, not to mention that people may have
>> more complex setups anyway (e.g., not setting $LANG but setting some of
>> LC_*).
> 
> 
> When 'locale charmap' prints 'UTF-8' the terminal can be assumed to be
> able to accept UTF-8 characters.
> 
> 'locale charmap', I think, determines this only based on environment
> variables.
> 

Hi Yuri,

Even if the terminal supports UTF8, will it print it properly? The font
used could have no or minimal utf8 support. Even when it's supported,
some characters might look alike and this could have undesired
consequences (ex accidentally switching from a normal space to a
non-break space while renaming a file that has spaces...).

I believe repos with utf8 files are rare enough and it could be left to
the user to select whenever to use utf8 or not... An option like "auto"
or "detect" could make it automatic but I'm not convinced it should be
the default.


Oh, and looking at "locale charmap", it doesn't check the terminal
capabilities at all - it just prints the charmap based on LC_ALL or
LC_CTYPE value, or default if they're unset. It doesn't mater what
terminal you're on...

Regards,

--
Thomas



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux