🚀 go-pugleaf

In article <C0MKEu.5or@poel.juice.or.jp>, erik@poel.juice.or.jp (Erik M. van der Poel) writes:
> 
> The way I see it, Plan 9 is itself an island.

I'm not sure at all that Plan 9 _is_ an island;  utf and 9P have been
published, you can actually read all of the documentation and understand
it (in contract to things like X and the almost unbounded number of RFC's),
it's more `open' than anything else that goes by the same moniker.

Reminds me of Geoff Collyer's comment [in ;login:] that the [PDP] 11/70 was
`open' because you could get the documentation, read it and build something.
It seems that the wheel has turned full circle in that it's again difficult
to build things because of the intentional (or otherwise) complexity,
obscurity and the broken set of tools to hand.

And while I'm at it, I think that GNU are as much a part of the problem rather
than the solution.  Yes you can get the source, but it's of no use because
it has been crippled by comlexity.  Look at gcc: a zillion command line
options when it should probably have _less_ than 5; the compiler should
just compile a program that adheres to the language spec, no more, no less.

So, what's my plan?  Talk utf and 9P and get some connectivity happening.
TCP/IP access to a public 9P file-server would be a start.  I'd almost be
tempted to `teach' NFS about 9P.  Yes, I'm probably that crazy.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''

>They currently use environment variables (e.g. "LANG") for "file
>typing".  This is how they can use the same "vi" binary in both Japan
>and Germany.

Actually, if they use the same "vi" binary in Japan, Germany, *and* the
US, they don't do Japanese EUC, because the "vi" that comes with SunOS
4.1[.x] is derived from the SVR3.1 one, which only does 8-bit character
sets.  They may have a "vi" that does 16-bit character sets as part of
Asian localization kits, and maybe the SVR4 "vi" that I assume comes
with SunOS 5.x handles 16-bit character sets.

The 4.1[.x] character-set handling stuff is set up to handle multiple
types of character sets, not just EUC, and that may be the way they
handle Unicode/UTF as well - depending on the setting of LANG, it'll do
ISO 8859/1, or 8859/n, or Japanese EUC, or Unicode/UTF, or....

They may also supply a program or programs to turn "plain text" files in
those character sets into UTF files, and to do the same with directories
(i.e., renaming files so that a file with a non-ASCII name in the
character set in question gets a new name that's the same name in UTF,
and possibly also fixing symbolic links).

Or they may do something else.

In article <C0MKEu.5or@poel.juice.or.jp> erik@poel.juice.or.jp (Erik M. van der Poel) writes:
>One conceivable approach is to extend this rudimentary
>file typing to actual file attributes ("groan, not this guy again" I
>hear all of you saying), extending NFS as well with a negotiated file
>type option.

This is the approach I advocate; I have already made a version of the
4.3 UFS (for 386BSD) which includes per-file locale typing.  For a
multilingual document, this type is LL_MULTILINGUAL... monolingual
documents have a locale specific typing based on the language used.

The big problem, as Ohta pointed out, is the "cat" problem.  I have this
solved for all but one pessimal case.  This is fairly easy if you handle
several issues up front:

o	All file arguments to cat are checked for type; cat is linked
	with a library (I have not yet made it a shared library, but
	I will) which can convert from monolingual to a simple format
	for embedded multilingual.  To do this, I have stolen several
	code points within Unicode for locale attribution; in a font,
	these code points would be represented as non-spacing blanks.
	These code points are embedded in the output stream as the
	conversion from attributed monolingual to multilingual takes
	place.

o	All in-core file descriptors must handle language attribution
	via ioctl.  This allows language attribution of pipes by
	type, as well as assignment of locale information to files
	created by redirection of the output to "cat".

o	Output coercion.


Currently, I am only forcing attribution, not "compact storage" using a
per language 8-bit spanning set.  I expect this to provide a reduction
to pre-international storage for small glyph-set languages, as well as
interoperability with existing non-internationalized systems.

The pessimal case which is disallowed is the input through a pipe of
multiple streams of non-monolingual data which would thus result in
a loss of attribution (unless interchange was always done using the
in-band attribution -- I felt this would be "bad").  For those of you
who are having a hard time coming up with an example of this case:

	:
	# pessimal use of cat with attributed data
	#

	for i in file.1 file.2 file.3
	do
		cat $i
	done | cat > file.multi

Some may note that the construct:

	:
	# questionable case
	#

	for i in file.1 file.2 file.3
	do
		cat $i
	done > file.multi

Should fail also.  This is not the case, because output is coerced to
be multinational by the shell providing the transitional stream for
the output of each of the "cat" commands (stdout), which is attributed
with a non-modifiable attribute which is checked by "cat" before it
decides on the output format.

This does have the drawback that the case of "file.1", "file.2", and
"file.3" containing data in the same monolingual locale result in a
"multilingual" file on output.  I'll respond that the proper mechanism
for the operation in question is:

	:
	# proper way to do questionable case

	cat file.1 file.2 file.3 > file.multi

and that even if this isn't observed, the resulting file is both usable
and "compactable" to a non-multilingual locale, perhaps by a post-pass
mechanism running as a cron job.

If you are interested in a more general discussion of file system
attribution and transport extension (since, as you suggest, an NFS
extension could be useful for homogenous internationalized systems,
thus avoiding "the island problem"), you should check out John
Heidemann's papers on Ficus (available by anonymous FTP from ftp.ucla.edu)
and David Rosenthal's "Evolving the vnode interface" in the June 1990
USENIX Conference Proceedings (pages 107-118).


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------

In article <1993Jan11.190644.29108@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
> The big problem, as Ohta pointed out, is the "cat" problem.

No, the big problem is the "editor" problem. "cat" has no business doing
anything but concatenating files. Why would you expect different character
set monolingual files to change format when you "cat" them? I certainly
wouldn't, any more than I'd expect "cat" to decompress compressed files,
convert a "tar" archice to a "cpio" archive when you cat one onto the other,
and generate a nicely formatted directory listing when you "cat" a directory.
These all make as much sense as your proposal.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

In article <keld.726930296@login.dkuug.dk>
	keld@login.dkuug.dk (Keld J|rn Simonsen) writes:

>> The big problem, as Ohta pointed out, is the "cat" problem.
>
>The cat problem is not a big problem, for text files.
>You can just automatically convert all of the input files,
>which can be in different coded character sets, into the
>coded character set of the output file.

If you can't 'cat' two text files just as two binary files,
the OS is not UNIX.

						Masataka Ohta