HDTenEightyP/NetNews huggingface dataset:
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Test suite problems
Date: 27 Dec 1992 18:21:49 -0800
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)

In article <1him24INNfct@ftp.UU.NET> johnl@iecc.cambridge.ma.us
(John R. Levine) writes:
>The problems that people have pointed out with the POSIX tests demonstrate
>that it is not appropriate to standardize test suites, particularly not
>test suites that haven't themselves been tested by a significant amount of
>use.

We haven't been discussing standardizing test suites but rather
test methods (lists of assertions).

>I'm all in favor of test suites.  I think there should be lots of them,
>since they make the implementor's design so much easier, and raise the
>user's confidence that a product that passed the tests probably works.
>But test suites make poor standards.

That's why the current practice is to standardize just the
test methods, largely a specification of the assertions
that a test suite has to test.

Once the standards process has determined that the test
methods properly express the base specification, the test
suite implementors have a specification for the tests and
the users of the tests have a way to examine the tests for
correct behavior.

This raises the hope that implementors will be able to
produce products that faithfully reflect the base standards,
without ever having to work around test suite bugs.  This
requires, of course, that the certifying authorities, the
test suite implementors, and the standards committees all
be responsive to problem reports.

--
Chuck Karish          karish@mindcraft.com
(415) 323-9000 x117   karish@pangea.stanford.edu

Volume-Number: Volume 30, Number 3
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re; PATH_MAX
Date: 23 Dec 1992 13:28:40 -0800
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)

In article <1gs9qaINN9rl@ftp.UU.NET> eric@mks.com (Eric Gisin) writes:
>On a system with a defined, constant value for PATH_MAX,
>what would pathconf("/tmp", _PC_PATH_MAX) return?
>The books I have, Zlotnick and O'Reilly, say PATH_MAX-4.
>The systems I have say PATH_MAX.
>Who is right? If it is PATH_MAX-4, how would fpathconf work?

POSIX.1-1990 says, in note (5) to Table 5-2 (5.7.1.3):

    If path or fildes refers to a directory, the value
    returned is the maximum length of a relative pathname
    when the specified directory is the working directory.

However, the description of the values in Table 2-6,
which includes PATH_MAX, (2.8.5) says:

    The values in Table 2-6 may be constants within an
    implementation or may vary from one pathname to
    another.

The implementation described above chooses to have
{PATH_MAX} constant rather than variable according to
the length of the path prefix.  This is legitimate.

Another interesting question is whether the fixed value
of PATH_MAX accurately reflects the capabilities of
the filesystem.
--

    Chuck Karish          karish@mindcraft.com
    (415) 323-9000 x117   karish@pangea.stanford.edu


Volume-Number: Volume 29, Number 83
From: cflatter@NRAO.EDU (Chris Flatters)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Date: 23 Dec 1992 15:21:40 -0800
Organization: NRAO
Reply-To: cflatter@NRAO.EDU
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: cflatter@NRAO.EDU (Chris Flatters)

In article 1halvbINN9kd@ftp.UU.NET, stephe@usenix.org (Stephen R. Walli) writes:
>....  One should assume that the standard is based on
>existing practice for the most part. That existing practice is in a
>particular programming language for API type standards.  Those will be
>the first people to come forward to develop the standard. (There has
>to be a need to standardize.)

Actually, producing a language independent specification plus language
bindings is already an existing practice for API standards.  Both the
ISO/ANSI GKS and PHIGS standards have this form.  The only aspect of the
POSIX effort that cuts new ground is the use of LI specifications to
approximate existing APIs.

	Chris Flatters
	cflatter@nrao.edu


Volume-Number: Volume 29, Number 88
From: knighten@intel.com (Robert L. Knighten)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Date: 26 Dec 1992 20:55:56 -0800
Organization: Intel Supercomputer System Division, Beaverton, OR
Reply-To: knighten@SSD.intel.com (Bob Knighten)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: knighten@intel.com (Robert L. Knighten)

In article <1him24INNfct@ftp.UU.NET> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>I think we need to step back a little and consider what appears to me to
>be the root of all the standardization trouble: standards should codify
>existing practice, or at worse choose from among a few existing versions
>of existing practice, perhaps with some minimal glue where the selected
>versions don't match up perfectly.  Invented standards usually fail.

This is a commonly expressed claim ("standards should codify existing
practice") and it may even be true for software, but I would certainly like to
hear some justification.  Certainly it is not true for a great many other
standards, such as many computer hardware standards, standards for electrical
fixtures and building standards, where specification of a standard often
preceeds the existence of any product.  Indeed there are numerous situations
where this is enforced by law.

Certainly invented standards usually fail, but then most standards (not just
software standards) fail in the sense that they have no significant impact on
commercial practice.  Do invented standards fail more often than those which
codify existing practice?  Indeed how is it to be decided which standards fall
in each category?

--
Robert L. Knighten	             | knighten@ssd.intel.com
Intel Supercomputer Systems Division | 
15201 N.W. Greenbrier Pkwy.	     | (503) 629-4315
Beaverton, Oregon  97006	     | (503) 629-9147 [FAX]


Volume-Number: Volume 29, Number 99
From: cflatter@NRAO.EDU (Chris Flatters)
Newsgroups: comp.std.unix
Subject: Re: POSIX Question
Date: 23 Dec 1992 15:20:40 -0800
Organization: NRAO
Reply-To: cflatter@NRAO.EDU
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: cflatter@NRAO.EDU (Chris Flatters)

In article 1hals4INN9hm@ftp.UU.NET, jgd@csd4.csd.uwm.edu (John G Dobnick) writes:
>Does the user interface standard (or whatever it's called) make
>any reference to the "vacation" program -- i.e., is vacation(1) 
>a required or optional part of a POSIX implementation.

It wasn't in the last draft of POSIX.2a (the User Portability Extension or
UPE) that I have (draft 8).  Nor is it listed among the utilities considered
but omitted.

For reference: the commands covered (not counting modifications to POSIX.2
commands) are (were?).

alias		at		batch		bg		crontab
csplit		ctags		df		du		ex
expand		fc		fg		file		jobs
man		mesg		more		newgrp		nice
nm		patch		ps		renice		split
strings		tabs		talk		time		tput
unalias		unexpand	uudecode	uuencode	vi
who		write

Considered but excluded were

SCCS/RCS			compress/uncompress/zcat
emacs				lint
m4				passwd
sdiff

	Chris Flatters
	cflatter@nrao.edu


Volume-Number: Volume 29, Number 87
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 1 Jan 93 22:27:01 GMT
Organization: CWI, Amsterdam

In article <1i2durINN2pj@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
 > >If so, what are the consequences,
 > 
 > The good spell-checker will suggest to replace the letter with the
 > correct one.

I can imagine the confusion:
  spelling error, suggested replacement "a for "a.
 > 
 > >Moreover, one question: how would you encode the German A-umlaut such that
 > >it sorts properly (i.e. as if it is the letter combination AE)?
 > 
 > The sorting order should be strict -- if you have two identical words
 > with a-umlaut and ae in the middle is it the same word? If it is then
 > ae IS a variation of a-umlaut and should always be treated as a signle
 > letter.
 > 
I do not think you understand.  From the AVON (Amtliches Verzeichnis der
Ortnetzkennzahlen) edition 1985, which gives area codes for the places in
Germany.  The next is a selection of places mentioned ("o is o-umlaut):
	Modautal
	M"ockm"uhl
	...
	M"ornsheim
	Moers
	M"ossingen
	...
	M"otzingen
	Mogendorf
now come up with a coding that allows this (standard German) sorting.
Note that it is not allowed to spell Moers as M"ors, that is a severe
spelling error!  On the other hand in the absense of umlauts it is
allowable to spell "o as oe (because it is in fact a shorthand for it),
but to do so when there are umlauts available does not look very good.
 > 
 > >Even in
 > >a single language (German) you can not come up with a coding that gives
 > >proper sorting. 
 > 
 > You can come with a reasonable approximation anyway.

If so, what do you deem reasonable in this case?
...
 > Forget about "traditions" -- users do not care which code is inside if
 > it looks like their usual stuff.

So users are completely uninterested in the coding and the sorting algorithm
used!
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.std.internat
From: dan@watson.ibm.com (Walt Daniels)
Subject: Re: An alternative I18N paradigm
Date: Tue, 29 Dec 1992 15:26:34 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<1hncs1INN1qq@corax.udac.uu.se>
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

I agree that having **only** an international locale would be a
disservice to many people. However such a locale would perform a very
valuable function. Namely establishing a base from which many locales
can be derived by a small set of changes. For instance a Spanish
locale is almost identical to a French locale except for some changes
to sorting and the spelling of the names of the months. I am assuming
that an international locale would have ISO 10646 as its codeset. Both
the French and Spanish would probably agree with the Japanese sorting
rules for instance, as well as the various numeric sets of characters
that are used in a number of languages. A full locale description
appropriate to ISO 10646 will be very large. Most local locales will
be small changes to it.

There is another useful role that an international locale can play.
The current definitions of locale do not carefully distinguish between
two roles that locales play. One role is as a tag describing the
contents of a file. The other role is as a user preference of how s/he
wants to view the data. The codeset part of a locale is always a tag.
The LC_MESSAGE category is always a user preference. Some of the other
categories are sometimes a tag and sometimes a preference. These two
roles must be separated. One way of treating an international locale
is that it is always the stored form of the file. All other locales
should be interpretted as user preferences.  
--


Walt Daniels         (IBM)<dan@watson.ibm.com>      914 784-6736
                     (Internet)<dan@watson.ibm.com>
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Future extension of ISO 10646
Date: 31 Dec 1992 23:51:16 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de

ISO 10646 defines a 32-bit character set, but at the moment, only
a subset compatible with Unicode (the multilingual base plane) that
fits in 16 bit has been defined.

How will the rest of the ISO 10646 character space be used? Will
there be a position for each character in each language (e.g. the
character defined by the lower 16 bits and the language indicated
by the higher 16 bits)? If mapping of full-10646 to the current
16-bit subset is still possible, that this would be a nice solution for
many sorting, upcase-conversion and hyphenation problems. Then
there would be

  - a universal A with diareses in the range 0-65535
  - a German version outside outside the 16-bit range
  - a Swedish version ...
  - ...

Are this the plans for the full ISO 10646 standard?

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
Newsgroups: comp.std.internat
From: lehotsky@down.osf.org (Alan Lehotsky)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Open Software Foundation
Date: Thu, 31 Dec 1992 16:51:26 GMT


Regarding Peter's observation that dumb software incorrectly expands
"St. Botolph St." as "Saint Botolph Saint", I should point out that
the earlier drafts of POSIX.2 addressed this problem by supporting a
syntax in the LC_COLLATE category for context-sensitive symbol
substitution.  This appears to have been withdrawn from the final
drafts (perhaps due to a belief that it was not arbitrarily powerful).

Still, in OSF/1, we implemented the 'substitute' construct.  This
permits BRE's in the string expressions so that you can say something
like:

	substitute "\(.*\)St\.$" with "\1Street"

	substutute "St\([e]\)\. \(.*\)" with "Saint\1 \2"

and (if I haven't made some stupid mistake with the syntax) get
strcoll() to do the right things.  [The second case even handles
female saints correctly!]

-- Al Lehotsky

Newsgroups: comp.std.internat
From: peter@ferranti.com (peter da silva)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: ISO10646 Unicode
Organization: Xenix Support, FICC
Date: Fri, 1 Jan 1993 23:19:06 GMT

In article <1i13rrINNars@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
> We were talking about lexicographical sorting, not abouth phonetics.

But lexicographic sorting (actually, lexicograhic ordering) is a minor part of
this. Most sorting computers do is algorithmic ordering, to optimise some
combination of operations on data structures (searching, for example). The
character set is irrelevant there.

> Then you KNOW that it is compressed graphical format -- which is
> essentially useless in anything except for storing and then reproduction
> of the text.

Yes.

> What makes encoded text useful is that its encoding extracts
> some SEMANTIC allowing for mechanical processing (particularly sorting).

OK, I want a character set that differentiates a word (if) between a C language
keyword (if(...)), command line options (dd if=...), and English text (if you
pass this way again...).

I want a character set that differentiates between parts of speech.

I want a character set that differentiates between running text, "quoted
running text", EMPHASISED RUNNING TEXT, references(1), Proper Nouns, and
<courier>computer text</courier>.

You don't want a character set. You want an SGML DTD.

> The semantic in ASCII is hard-coded -- it is the order of letters
> and the trivial upper-case to lower-case convertion.

<para><sentence><phrase>The semantic in <acronym>ASCII</> is <jargon>
hard-coded</></><dash><phrase>it is the <phrase>order of letters</>
and <phrase>the trivial <jargon>upper-case</> to <jargon>lower-case</>
conversion</></></sentence></para>
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: Christopher.Vance@adfa.oz.au (Christopher JS Vance)
Subject: Re: What are the ISO paper sizes? (Was: An alternative I18N paradigm)
Originator: cjsv@ccadfa.cc.adfa.oz.au
Organization: Computer Science, University College, UNSW/ADFA, Canberra, Australia
Date: Sun, 3 Jan 1993 23:09:05 GMT

In article <cline.725593960@ebony.cs.scarolina.edu> cline@usceast.cs.scarolina.edu writes:
| unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:
| 
| |  - use ISO paper sizes (e.g. A4, C5, ...)
| 
| Not a good idea. Here in the US it is almost impossible to obtain ISO sized
| paper. Most paper is based on two standard sizes letter and legal or a
| fraction or multiple therof.
|   Letter (8.5" x 11") [21.59cm x 27.94cm]
|   Legal  (8.5" x 14") [21.59cm x 35.56cm]

So what?  I'm not particularly worried about 5% of the world using
nonstandard paper.  I'm sure they don't use (quite) half the world's
paper, so they're definitely a minority.  (I can't get US sized paper
either, but I'm part of the 95%, so I'm okay...)

| However, what I would like to know is what size is A4 or C5 or the rest
| of these map references that ISO uses for paper.
| Please reply by e-mail or posting with either the sizes or suggestion on
| where to look for a listing of _all_ the sizes.

Any book listing standard paper sizes....  I left mine at home.  Once
you know the size of A0 and B0, you can trivially calculate the rest
of the A and B series.  I can't remember if the C series (envelope
sizes) are quite as sensible.

-- Christopher
Newsgroups: comp.std.internat
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 1 Jan 1993 11:41:58 GMT

In article <1i0s05INNnfn@rodan.UU.NET>, avg@rodan.UU.NET (Vadim Antonov) writes:
> 
> A good encoding should support easy (i'd say natural) localization.
> It should provide simple algorithms for simple functions
> like getting string length, searching a character, case-insensitive
> comparison, lexicographical comparison.
> 

Well that's where you're wrong.  The characters and how they are used
are distinct problems.  Merging them will just not work.  UNICODE is
a good example of this:  not only does it specify the code -> glyph
mapping (ie the encoding) it has support for left -> right, right -> left
writing styles and a bunch of other stuff, and this part of UNICODE is a mess.

Problem 2 (localisation) is damn hard.

Should Problem 1 cater for the fact I type `localisation' whereas
you type `localization'?  We're both using Engligh, typed on American
keyboards (I guess, oops mine's made in West Germany) so where are you
going to draw the line.  Is this Problem 1?  I say it's Problem 2.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.std.internat,news.admin.misc
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: 8-bit news
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Sun, 27 Dec 1992 16:06:25 GMT

We run a lot of ISO Latin-1 here -- I hate it; there are just too many
things that break when they see 8 bit characters, and I'm usually the one
who has to _hack_ 8 bit cleanliness into things.  Don't get me wrong, I'm
all for 8 bit clean code.  Once we have that, just run Plan 9 utf  -- end
of problem.  Pushing Plan 9 utf should make everyone happy; it's clean,
simple and it _works_.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.std.internat,news.admin.misc
From: berger@imag.fr (Gilles BERGER SABBATEL)
Subject: Re: 8-bit news
Organization: Institut Imag, Grenoble, France
Date: Tue, 22 Dec 1992 17:28:12 GMT

dhd@exnet.co.uk (Damon) writes:

>So use something like MIME which can cope with a much bigger character
>set than 8-bit and begin to solve the problem for all (human, natural)
>languages.

>IE, don't be parochial and assume that because it solves *your* problem
>it's more then moving from a 1% solution to a 1.1% solution...

Sure!  But the problem is that we could relatively easily move to
ISO-latin-1, (many softwares appear to work with 8 bits chars) so that
it would be a first step to experiment and solve the problems.  Whenever
news solutions are to be found, they must take in consideration the
existence of languages which does not use ISO-latin-1, ie. conversion tools 
should be general enough.

>(An Englishman telling a Frensh person not to be parochial.  B^>)

>And funnily enough, MIME doesn't need 8 bits and the changing of all
>the existing software, does it?  It may be ``simply anachronistic'' to
>be forced to converse in accentless Latin script to communicate
>electronically, but is it *clearly* *simply unreasonable* to make
>*everyone* convert *all* their mailer/news software to solve your
>unique problem when there is a solution which is more general and less
>intrusive.

First, ISO-latin-1 appear to require a minimal conversion of softwares,
as many system work without modifications (this is the case for C-news
with nntp-1.5.11, and newsreaders such as nn, tin, xrn, rn).  Second,
it is only required for people who use such character sets.  I would
not mind using standard ASCII chars to write english... and I am not
able to write japanese at all!  So, the use of ISO-latin-1 in France
would not disturb anybody outside of France, and it contributes to the
solution of the problem - at least it poses it!
--
Gilles BERGER SABBATEL                  Tel: (33) 76 57 46 13
Laboratoire d'appartenance : TIM3
IMAG-LGI/INPG, 46 Avenue Felix Viallet, 38031 GRENOBLE CEDEX - FRANCE
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
Date: 31 Dec 1992 07:15:08 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu

In article <2563@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>
>I heard that, microsoft's NT will have a locale mechanism so that
>it can print Japanes Han as Japanese and Chinese Han as Chinese,
>which is impossible with bare 10646/Unicode.
>
>Then, how can we have a file containing both Japanese and Chinese?
>

Ohta-san is making much too much about this issue.  First, there is
much less difference between a Chinese font's rendition of a given Han
character and a Japanese font's rendition of the same character than
he seems to imply here.  Indeed, in practice, it is merely a matter of
a font difference.  Furthermore, should a Japanese reader see a 10646
Han character displayed with a Chinese font, or, should a Chinese reader
see it with a Japanese font, it will still be legible in general.

If one wants a 10646 encoded text containing a mixture of Chinese and
Japanese to be displayed using different fonts for the Chinese and Japanese
parts, then a higher level protocol (rich text) must supply the information
needed to determine which text is Chinese and which is Japanese.  This can
be accomplished indirectly by using font runs, or directly by using some
form of language tagging.

This is no different from wanting to display English text with a mixture
of regular and italic faces.  10646 can't tell you which characters should
be displayed with an italic font either.  The key point is that, in the
absence of font shift information, one can still read the text.  Since this
is also true in the mixed Chinese/Japanese case, it is an equivalent problem.
10646/Unicode properly encodes only the "plain text" information which
allows for legible display.  Applications which desire more sophisticated
display will have to add other "rich text" information necessary for the
control of such advanced display.  The Unicode plain text model considers
display with multiple fonts to be a sophisticated display requiring
appropriate font tagging or other data (e.g., language tags) which allows
the proper font to be selected.

Glenn Adams
Cambridge, Massachusetts
Newsgroups: comp.std.internat,news.admin.misc