This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cyg1.7 - DOS character remapping: change request.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]