[freetds] status and stability

Varley, David (CBorn at Alcoa) David.Varley at alcoa.com.au
Thu May 15 02:39:19 EDT 2003


You seem to have found the same man-pages I was using :)
I don't even have a /usr/lib/nls/loc/iconvTable on my system.
I thought perhaps some standard conversions might be handled
internally, so I tried running iconv with some of the standards
mentioned in the man pages, such as UTF-8, but got the message
"cannot open converter".
When I ran iconv under sctrace it tried opening the conversion
files, algorithmic and table, from /usr/lib/nls/loc and also
from /etc/nls/loc, and failed when none were found.

A machine with an older version of DU had even less converters
to choose from (1 !) and my US-based systems appear to be
offline at present, but there is probably an install kit that
adds the extra converters somewhere, I'll check in the factory
later.

As to what I require, it worked fine for me without all this
iconv stuff, I'm happy for it just to go away :)))

David

> -----Original Message-----
> From: James K. Lowden [mailto:jklowden at schemamania.org]
> Sent: Thursday, 15 May 2003 3:07 PM
> To: FreeTDS Development Group
> Subject: Re: [freetds] status and stability
> 
> 
> On Thu, 15 May 2003 11:57:58 +0800, "Varley, David (CBorn at Alcoa)"
> <David.Varley at alcoa.com.au> wrote:
> > Jim,
> > 
> > From what I can see, the conversions are:
> > 
> > ISO8859-1-GL_ISO8859-1
> > ISO8859-1-GR_ISO8859-1
> > ISO8859-1_ISO8859-1-GL
> > ISO8859-1_ct
> > 
> > with aliases by symbolic links as:
> > 
> > ct_ISO8859-1ASCII-GR_ISO8859-1 -> ISO8859-1_ISO8859-1-GL
> > ISO8859-1_ASCII-GR -> ISO8859-1-GL_ISO8859-1
> > ISO8859-1_ISO8859-1-GR -> ISO8859-1-GR_ISO8859-1
> > ISO8859-1_fold7 -> ISO8859-1_ct
> > ISO8859-1_fold8 -> ISO8859-1_ct
> > fold7_ISO8859-1 -> ct_ISO8859-1
> > fold8_ISO8859-1 -> ct_ISO8859-1
> > 
> > if this is of any help. My version of iconv doesn't support the
> > --list option of the GNU one, I've just taken these from the
> > /usr/lib/nls/loc/iconv directory (algorithmic converters).
> 
> It's ~some~ help.  What I need to know is, what encodings 
> those are.  For
> lack of a better term, I need their GNU names.  I found this [1]:
> 
>   [Tru64 UNIX]  Current industry standards do not specify the 
> name format,
>   implementation, and location of the codeset converters used 
> by this com-
>   mand.  On this operating system, the command searches directories of
> algo-
>   rithmic and table converters to find one that performs the requested
>   conversion. The names of codeset converters adhere to the following
> format:
> 
>   fromcode_tocode
> 
> I have to think your support is broader than those names, 
> too, btw.  You
> mentioned "/usr/lib/nls/loc/iconv/".  What about table converters in
> /usr/lib/nls/loc/iconvTable ?
> 
> The work of establishing the meaning of all those conversions 
> may well be
> more than you care to take on.  That's fine.  What we need at least is
> Frediano's favorite four, plus any you require.  (From what I 
> understand,
> you require ASCII and nothing else, yea?)
> 
> FFF are:
> 
> 	ISO-8859-1
> 	UTF-8
> 	UCS-2LE
> 	UCS-2BE
> 
> Freddy, Tru64 introduces a couple of other things to noodle 
> around.  It
> uses environment variables to control iconv behavior.  These 
> might just be
> documentation notes; I don't know.  They are:
> 
>   ICONV_BYTEORDER
>       Sets byte ordering for UCS-2 or UCS-4 converters
> 
>   ICONV_DEFSTR
>       If these variables are not defined or are set to the 
> null string,
> the
>       characters that cannot be converted are skipped and have no
> representa-
>       tion in converted output.  [Not GNU's behavior!]
> 
>   ICONV_NOBOM
>       Disables generation of the byte-order mark at the 
> beginning of UCS-2
> or
>       UCS-4 output. 
> 
> --jkl
> [1] http://btrcx1.cip.uni-bayreuth.de/cgi-bin/manpages/iconv/1
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 



More information about the FreeTDS mailing list