From donn@hpfcrn.fc.hp.com Mon Sep 23 19:41:03 1991
Received: from relay.hp.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA05489; Mon, 23 Sep 91 19:41:03 +0200
Received: from hpfcrn.fc.hp.com by relay.hp.com with SMTP
	(16.6/15.5+IOS 3.13) id AA12313; Mon, 23 Sep 91 10:40:44 -0700
Received: from hpfcdonn.fc.hp.com by hpfcrn.fc.hp.com with SMTP
	(16.7/15.5+IOS 3.22) id AA23474; Mon, 23 Sep 91 11:40:17 -0600
Message-Id: <9109231740.AA23474@hpfcrn.fc.hp.com>
To: Keld J|rn Simonsen <keld@dkuug.dk>
Cc: greger@ism.isc.com, hlj@posix, wg15rin@dkuug.dk
Subject: Re: (wg15rin 145) Re: Ballot resolution 
In-Reply-To: Your message of "Sat, 21 Sep 91 21:56:06 N."
             <9109211956.AA19578@dkuug.dk> 
Date: Mon, 23 Sep 91 11:40:16 MDT
From: Donn Terry <donn@hpfcrn.fc.hp.com>
X-Charset: ASCII
X-Char-Esc: 29


First, I'd rather have it as in D11 than as it is now.

Secondly, I havn't spent enough time with EBCDICs to know all the details,
so I'll take your word for it that not all EBCDICs contain #.

However... what will those implementations do for sh and awk and all the
other things that need #?  They're going to have to solve the problem in
some way.  (I'll take that as a given.)

They *will* have to substitute something for #.  Whether when doing that
the implementation is strictly standard conformant I don't want to get into.
(Or they absolutely insist that there's only one translation, which is
to the 8859-like EBCDIC, which always has #.)

Whatever character they end up using for # is # in shell, # in awk, and
should be # in localedef!  Thus, I don't see that EBCDIC has the problem
in the same sense as 646.  (At least they have a place to put it and
the national characters; 646 just doesn't have room!)

I believe that any reasonable POSIX on a EBCDIC implementation would
insist that the 8859-like EBCDIC be the only character set supported.
(On a hosted system, it might support other variations in the non-POSIX
environment, but withing POSIX...)  The historical uglyness of 646
(because of its 7-bit nature) should not affect an inherently 8-bit
character set.

I don't see any reason why, in an EBCDIC environment, localedef can't 
count upon having # available.

Donn