On 02/18, Mark Rivers wrote:
> There is one thing I do not understand is why grep finds the non-UTF8
> characters on Fedora 26, but apparent not on RHEL 7? These are the
> same physical file on disk. Can someone explain this?
Hi, Mark.
The locale settings might be different. You can run the "locale"
command on both of those machines to show the current locale
and compare the output. The locale settings can be changed by
setting environment variables, so you can play around with it
fairly easily. "locale -a" lists all available locales. You can
use the LC_ALL environment variable to override the LANG and LC_*
environment variables. The format of the locale name is usually
"language[_territory][.codeset][@modifier]". On RHEL 6, the
setlocale(3) man page gives more info.
For example, in a Bourne shell, you could try:
$ LC_ALL=en_US.utf-8 grep -axv '.*' cmstypes.c
You could of course then change the value of the LC_ALL environment
variable to set the locale to match each of your two machines to see if
you can reproduce the behavior you're seeing.
Regards,
Lewis
- References:
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Gofron, Kazimierz
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Gofron, Kazimierz
- Re: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Gofron, Kazimierz
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- Re: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Johnson, Andrew N.
- RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- Navigate by Date:
- Prev:
Re: NSLS-II Debian Repository in 2018 Michael Davidsaver
- Next:
Re: NSLS-II Debian Repository in 2018 Carlos Pascual
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s) Mark Rivers
- Next:
Dexela .dll missing when compiling WITH_PVA=YES Gofron, Kazimierz
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|