Re: exmh_addrs address database truncated

In the message dated: Wed, 10 Oct 2007 20:27:14 PDT,
The pithy ruminations from Dave Close on 
<Re: exmh_addrs address database truncated > were:
=> [email protected] wrote:
=> 
=> >For a given input file, the output (ie., after loading the database into exmh
=> >and then saving to the exmh_addrs file) is consistent. However, the output file
=> >size varies depending on the order of the input file, and the output file
=> >doesn't end on the same entry each time.
=> 
=> Perhaps the last good entry is different each time but what about the
=> next entry in the file for that sort order? Or the next few entries
=> (depending on buffering)? Perhaps there is something common there.
=> 


I've looked...repeatedly...but haven't found anything.

=> My guess is that there is some character in your file that the parser
=> doesn't like. It might be some special character that isn't used anywhere
=> else. It might be a character with the high bit set (so it looks normal
=> when displayed). Or it may well be a character that is invisible when
=> the file is viewed normally (such as a null). You might try od or some
=> other binary dump.

That's my guess too.

Hmm....that's got me thinking of a good way to check...

	cat -v exmh_addrs.full > strip_high_order_characters
	diff exmh_addrs.full strip_high_order_characters

nope, the two files are the same (meaning that no control characters were
found in exmh_addrs.full).

However, exmh seems to have no problem with iso-8859 encoding in addresses. The 
same number of entries with that encoding appears in both the source address 
file and the saved exmh_addrs database.


=> 
=> Since the problem just happened recently, you might concentrate on more
=> recent additions to the file.

Not necessarily....

I eliminated all the entries from 2007, and I still get the same behavior...the 
size of the address database depends on the order of the input file, and the 
saved address database can be less than 1% of the input file.

Thanks for the suggestions.

Mark

=> -- 
=>        Dave Close, Compata, Costa Mesa CA       +1 714 434 7359
=>        [email protected]              [email protected]
=> The most likely way for the world to be destroyed, most experts agree,
=> is by accident. That's where we come in; we're computer professionals.
=> We cause accidents.  -- Nathaniel Borenstein
=> 
=> _______________________________________________
=> Exmh-users mailing list
=> [email protected]
=> https://www.redhat.com/mailman/listinfo/exmh-users
=>