Re: debugger: will that work if grep wasn't built with debug symbols?  I think 
this one wasn't.

-----Original Message-----
From: Paul Eggert <egg...@cs.ucla.edu> 
Sent: Friday, August 9, 2024 5:57 PM
To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatin...@barclays.com>
Cc: 72...@debbugs.gnu.org
Subject: Re: bug#72524: how does grep determine locale if no LC environment 
variables are set

 CAUTION:  This email originated from outside our organization - 
egg...@cs.ucla.edu  Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe. 

______________________________________________________________________
On 2024-08-08 12:24, mark.yagnatin...@barclays.com wrote:
> Re: how am I doing that ... via bash, just like the way you suggested I run 
> "locale" the second time:
> LC_CTYPE=C.UTF-8 grep -P needle haystack.txt  # just CTYPE seems to be 
> enough, no need for ALL

As an aside, I wouldn't mess with LC_CTYPE independently. One can get into 
trouble if the LC_CTYPE locale disagrees with the others. However, I don't 
think that's your problem.


> Re: is_using_utf8 ... It relies on mbrtowc, which in turn relies on the 
> current locale.
> It seems that this function should NEVER return false in a UTF-8 locale.

Correct.

> But how does grep decide what the locale even is?
> Presumably it must call setlocale at some point, or else it would be using 
> the C locale, which is surely a unibyte locale.

Correct, it calls 'setlocale (LC_ALL, "")' first thing.


> is there any good way to find out what locale it actually got "resolved" to?

You could modify the source code to add a call like this:

    fprintf (stderr, "grep: locale is %s\n", setlocale (LC_ALL, 0));

after the earlier call to setlocale. Or you could run 'setlocale (LC_ALL, 0)' 
in a debugger.

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding 
marketing commentary from Barclays Sales and/or Trading desks, who are active 
market participants; 
https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Investment Bank where we trade with 
you in principal-to-principal wholesale markets transactions; and in respect to 
Barclays Research, including disclosures relating to specific issuers, see: 
https://publicresearch.barclays.com.
__________________________________________________________________________________
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: 
https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
  • bug#72524: how does gre... mark . yagnatinsky--- via Bug reports for GNU grep
    • bug#72524: how doe... Paul Eggert
      • bug#72524: how... mark . yagnatinsky--- via Bug reports for GNU grep
        • bug#72524:... Paul Eggert
          • bug#72... mark . yagnatinsky--- via Bug reports for GNU grep
            • b... Paul Eggert
              • ... mark . yagnatinsky--- via Bug reports for GNU grep
                • ... Paul Eggert
                • ... mark . yagnatinsky--- via Bug reports for GNU grep
                • ... mark . yagnatinsky--- via Bug reports for GNU grep

Reply via email to