Message-ID: <4B12F787.3050006@tlinx.org>
Date: Sun, 29 Nov 2009 14:36:55 -0800
From: Linda Walsh <cygwin@tlinx.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 ThunderBrowse/3.2.6.5 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: cyg1.7 - DOS character remapping: change request.
References: <4B0B21E0.3050909@tlinx.org>  <4B0B5433.8020603@byu.net>  <4B0B610D.6080709@tlinx.org>  <20091124085022.GR29173@calimero.vinschen.de> <20091124090646.GS29173@calimero.vinschen.de> <4B10FA45.6060605@tlinx.org> <4B111536.7090904@byu.net>
In-Reply-To: <4B111536.7090904@byu.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Eric Blake wrote:
> Rather than complaining, write a patch to prove your point.  Patches speak
> much louder than rants on open source projects.  But I won't be the one
> writing the patch.
----
	I already supplied code in the first email.  It's a matter of
using those constants instead of the ones being used.  

Corinna Vinschen wrote:
>> According to Linda Walsh on 11/28/2009 3:24 AM:
> 
>>> Any other standards group I know of is going UTF-8.  All of the
>>> linux distributions I know are going UTF-8.  I'd like to see Cygwin
>>> go that way too.
> 
> I don't understand this one.  What on earth are you think we're doing?
> Do you really understand the sense of the mapping?
---
	You are trying to allow use of the commonly usable
'7 banned chars' (under DOS) that are occasionally used
on Unix.  No?  The UTF-8 is referring to the fact
that the substitute chars I'm referring to would be
viewable on platforms using UTF-8 -- as the unicode
values in UTF-16 are directly convertible to UTF-8
platforms (which such wouldn't be the case to platforms
using not Unicode-based platforms).


> But that mapping doesn't make sense.  Instead of mapping valid, but
> forbidden characters into a range which doesn't contain valid
> characters, the valid characters are then mapped onto other valid
> characters.  How are you going to ever map them back?  When is a
> FULLWIDTH QUOTATION MARK actually a QUOTATION MARK and not really a
> FULLWIDTH QUOTATION MARK?  You're covering perfectly valid characters
> and make them unusable.  Besides, we have not only to map the few
> characters you're talking about, the U+f0XX range is also used to
> map invalid UTF-8 chars.
----
	I'm aware that this would reserve the 'display forms'
of those chars and map them them to their real forms when
interpreted within cygwin.  I don't see this to be a problem.

	There are no applications that currently use those
values because cygwin 1.5 didn't support either the real 
ascii values OR the unicode values.  It's a matter of
seeing those file names, produced by 1.7 as semi valid
values when viewed in explorer and when they are viewed
on linux servers.  _I_ use those values in filesnames,
and know of no compatibility problems having them
treated as 'real' ascii characters under cygwin --
since I am just using them for 'display' purposes
in file names like like "Music:the group:title 1/3".
In linux and windows, I'm using them as display forms.
I put quotes around the filesnames so whether they are converted
to real ascii forms under cygwin or stored as visual display
forms is of no consequence.

	I don't see a problem.  And the patch is just
changing the hex values used to the ones I supplied in
my original posting.

	Am I indicating an understanding of the problem
and implications?  Do you feel it's really a problem given
how they are commonly used and how there would be no 
conflicting applications?

linda


--
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