> John, I truly do not think you need to worry so much about UUENCODE. > I suggest you remain skeptical, but not about UUE. It is only > one example, and is much less problematic than others. > > > I think I used CP500 on OS/2. > > I think CP500 is an EBCDIC codepage, not an ASCII codepage. > (Loose use of the terms "EBCDIC" and "ASCII". Please be gentle.)
Could be - I choose something appropriate for "Western Europe." We have US keyboards here though. Back when DOS ruled my 386, one of my daughters did all her German homework using a US keyboard, Wordstar 2000, DOS, and she typed in all those funny letters using ALT and the numeric keypad! > > > The worst I get from this (being a heavy Pine user) > is a nasty message "I don't know how to handle that codepage > so it may look funny on your screen". Clearly the agent > (in this case Pine) is leaving the data intact. Good! Nice to know someone else here uses Linux for their email. I quite using PINE when I discovered it didn't play nicely with procmail;-( > > > When I build a kernel the only place there's mention of codepages > > is WRT DOS filesystems. > > > > I've just checked what modules I have loaded: > > nls_cp437 4320 0 (autoclean) > > nls_iso8859-1 2816 0 (autoclean) > > And what does this mean? > Does the FS driver perform translation? Ouch! I think they're used to display file names, nothing more. <snip> > There seem to be two places where "codepages" are considered: > one where translation MUST be applied, as in crossing an A/E boundary, > and another where translation MAY be applied, such as nationalization. > This is not to say that the latter is unimportant: surely my > Israeli friends would like to see Hebrew presented correctly. > > I submit to you all that, except for crossing an A/E boundary, > codepage application should be deferred until the latest possible moment, > not unlike how fonts are applied to web content. Choosing any other > point in the processing to insert NLS handling leads to 1) increased > code complexity, 2) increased processing load, and 3) content > corruption. For those with 1GHz and faster Pentiums, processing load > may not seem to matter, but does when scalability returns to prominence. > Code complexity leads to miserable programmers making miserable products. > And data corruption should strike fear in all our hearts. A long time ago, when the world was young (and I didn't have any grey hairs), I did some programming involving ASCII terminals and networks attached to OS/VS1 and OS/VS2. Those were days before codepages had been invented, and there was but one correct translation between the two. I don't have the foggiest idea how people who preferred other languages got on. In the times I've used IBM mainframes since then, those questions haven't arisen with regard to my duties. When the Internet came along, I was using OS/2, and the particular problem uuencoding gave me was that it wasn't supported in the (ever unreliable) Ultimedia Mail. Lots of others said there were transmission problems with uuencoding, and I could see clearly how those problems would arise. It's true I never saw them, but I'm not at all sure I received mail where they might have. If the problem is fixed (and I'm pretty sure I understand you) that's good. But I'd still test it. And I'd be extremely suspicious of anyone transferring data directly from one filesystem to another. I've seen LanServer running on MVS. I'd not trust that either without testing it;-) -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. ============================== If you don't like being told you're wrong, be right!
