EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  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  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: ADSupport compilation problem due to GraphicsMagick Malformed UTF-8 character(s)
From: "J. Lewis Muir" <[email protected]>
To: Mark Rivers <[email protected]>
Cc: "Gofron, Kazimierz" <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 20 Feb 2018 12:16:59 -0600
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  <20182019  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  <20182019  2020  2021  2022  2023  2024 
ANJ, 21 Feb 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·