Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Colin Walters
[ CC's trimmed, since mail to the bug will reach -policy ] On Mon, 2003-01-06 at 16:07, Jason Gunthorpe wrote: > Fixing progams that handle terminal input is a different matter IMHO, it's > something that should be decided on a more case by case basis, and alot of > cases might be effortless han

Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Colin Walters
On Mon, 2003-01-06 at 16:01, Jochen Voss wrote: > On Mon, Jan 06, 2003 at 12:21:27AM -0500, Colin Walters wrote: > > After we have a "sufficient" number of programs supporting UTF-8 > > natively in this way, we change the policy on filenames to a "must", > > drop support for legacy terminals and e

Online/ Phone

2003-01-06 Thread Accept
Title: CP_Mass

Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Jochen Voss
Hello Colin, On Fri, Jan 03, 2003 at 09:50:26PM -0500, Colin Walters wrote: > In summary, UTF-8 is the *only* sane character set to use for > filenames. At least I agree to this :-) I think that we need filename conversion between UTF-8 and the user's character set, because we cannot ban all non-

Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Jochen Voss
Hello, On Mon, Jan 06, 2003 at 12:21:27AM -0500, Colin Walters wrote: > After we have a "sufficient" number of programs supporting UTF-8 > natively in this way, we change the policy on filenames to a "must", > drop support for legacy terminals and encodings, and switch everyone to > a UTF-8 termin

Re: Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Jason Gunthorpe
On 6 Jan 2003, Colin Walters wrote: > Since we will have to change programs anyways, we might as well fix them > to decode filenames as well. The shell is kind of tempting as a "quick > fix", but I don't think it will really help us. Fixing progams that handle terminal input is a different matt

Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Colin Walters
On Mon, 2003-01-06 at 02:46, Jason Gunthorpe wrote: > I think you'd need to have all of argv be converted to utf-8 by the shell. Besides Sebastien's reply, there is another good reason not to do recoding in the shell: for any program which actually manipulates filenames, we will need to add Unico

Re: Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Jason Gunthorpe
On Mon, 6 Jan 2003, Sebastian Rittau wrote: > > I think you'd need to have all of argv be converted to utf-8 by the shell. > > This wouldn't work, since you're not able to handle files that are not > in UTF-8 encoding, then. This is especially bothersome if you have some > old non-UTF-8 files ly

Re: Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Sebastian Rittau
On Mon, Jan 06, 2003 at 12:46:46AM -0700, Jason Gunthorpe wrote: > I think you'd need to have all of argv be converted to utf-8 by the shell. This wouldn't work, since you're not able to handle files that are not in UTF-8 encoding, then. This is especially bothersome if you have some old non-UTF-

Add Inches

2003-01-06 Thread grjanwtkd
100% Money Back Guarantee! Permanent Larger Erections http://www.shaggweb.com/enlargement/index.html 8683Uvl6

Re: Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Jason Gunthorpe
On Mon, 6 Jan 2003, Richard Braakman wrote: > I guess this conversion should be done by the user's shell, and all > filename arguments on the command line should be encoded in UTF-8. > Umm, except that the shell doesn't know which arguments are filenames. > How should this be done? I think you'd

Bug#99933: second attempt at more comprehensive unicode policy

2003-01-06 Thread Colin Walters
On Sun, 2003-01-05 at 22:00, Richard Braakman wrote: > Hmm. Remember the far more common case of a program that takes a > filename on the command line and then tries to open it. The user > would have typed it in the local encoding, so it needs conversion. > On the other hand, if the program was