X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_50,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "cygwin@cygwin.com" Date: Fri, 26 Mar 2010 00:24:25 +0100 Subject: Re: UTF8 and cvs issues in 1.7.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: lemkemch@t-online.de Message-ID: User-Agent: Opera Mail/10.10 (Win32) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Erik Blake wrote: > On 03/25/2010 05:05 PM, lemkemch wrote: > > orion> cvs -qn up -l > > U Ãppel.txt > > cvs update: warning: `âppel.txt' is not (any longer) pertinent > >> And frankly, I can't see how the terminal could influence the > > behavior of the cvs executable. I am not talking about the > > displayed characters here but that cvs wants to update a file. >I wonder if the problem is that CVS/Entries was created under one > charset, but you are now using a different charset. I suppose you could > use iconv to convert the file to the correct encoding. Or it may be a > sign that cvs has not yet been recompiled to be charset-aware. Yes, that sort of it is. Further experiments show this: CVS/Entries written by 1.5: /äppel.txt/1.1/Thu Mar 25 22:14:59 2010// With 1.7 it changes to (module character corruption through e mail): /äppel.txt/1.1/Thu Mar 25 22:14:59 2010// The positive is that the cvs update doesn't actually change the file on disk. All that happens is changing CVS/Entries. Still annoying. The fix I found is setenv LANG C.ISO-8859-1 But somehow that doesn't smell right. Michael -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple