Xref: utzoo alt.folklore.computers:3516 comp.unix.wizards:22197
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!lightning.Berkeley.EDU!dankg
From: dankg@lightning.Berkeley.EDU (Dan KoGai)
Newsgroups: alt.folklore.computers,comp.unix.wizards
Subject: Re: filename separators and option indicators
Summary: '/' is good but none of CLI is intuitive enough
Keywords: separator, delimiter,~,`,!,@,#,$,%,^,&,*,(,),-,_,=,+,[,{,],},\,|,',",;,:,/,?,.,>,',',<
Message-ID: <1990May30.045903.14249@agate.berkeley.edu>
Date: 30 May 90 04:59:03 GMT
References: <8687@cs.utexas.edu> <150@rossignol.Princeton.EDU> <BZS.90May23210652@world.std.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: dankg@ocf.Berkeley.EDU (Dan Kogai)
Organization: ucb
Lines: 58

In article <BZS.90May23210652@world.std.com> bzs@world.std.com (Barry Shein) writes:
>
>>Using '/' for paths and '-' for options seems intuitive, especially '/'
>>for paths.  This is my guess why Thompson used them in Unix.
>
>Multics (the previous bad experience which inspired unix) used > for
>paths as I remember, with the reading of A>B>C as A "down" B "down" C.
>That's also pretty intuitive, but it was shifted which was probably a
>drawback (no, no, the > in the shell came later.)

	So Multics had no concept of "read to stdin" and "write from stdout"?
well, that could've been "->" and "<-" (This is not intercal!).  But among
a lot of CLIs, I love UNIX the best and always have trouble typing "A:\foo\bar"
but none of CLI implementation of delimiter will be intuitive enough.
On Macintosh, thanks to GUI, only ":" is reserved as delimiter and it's
directory delimiter.  That makes MPW users (Hi, robert!) hard to deal with
files but for the "rest of them" it's nice to be able to make such file names
as "Foo killed bar's blech".

>You also had considerations like printing your output on 64-character
>band printers which were missing some characters.

	Some guys have opposite problems:  Too many characters to handle.
it take at least 3,500 Kanjis (Nice iconic character from china) to handle
daily Japanese and it's even more for Chinese.  As for Japanese, there are
several standards going on currently and its complexity is nothing compared
to ASCII vs EBCDIC:  They have to use 16bit char instead of 8 but they also
want to use standard ASCII (I'm not sure how well EBCDIC is used in Japan).
So there must be delimiter to toggle 2byte char on and off.  One implementation
uses escape sequense.  Other uses uppermost bit as switch.  Basic index is
set by JIS (Japan Industory Standard, ANSI equivalent for the Japanese) but
even that has changed once--some characters are moved elswhere, some deleted
and some added.  (For sure fj.* newsgroup uses New JIS--New index, escape
sequence toggling, 7-bit compatible).  This pain is something alphabet users 
can hardly understand.
	And on some implementation of Japanese ASCII, some of punctuation chars
are replaced with others.  The funniest is that backslash is replaced with
yen figure ('Y' + '=').  And they are basically using the same DOS.  So instead
of bunch of backslashes, they see a lot of yen figures in their path string
(That applies to C's char quotation also!).  Think about it:

	$usr$local$bin$bash

	No wonder they are rich, huh? :)

	And I think that apply to other Indo-European language character sets 
also (Suppose British uses starling figure for the place of backslash?)  Come
to think there's no cent figure for ASCII.  Anyone know why?


----------------
____  __  __    + Dan The "Punctuated" Man
    ||__||__|   + E-mail:	dankg@ocf.berkeley.edu
____| ______ 	+ Voice:	+1 415-549-6111
|     |__|__|	+ USnail:	1730 Laloma Berkeley, CA 94709 U.S.A
|___  |__|__|	+	
    |____|____	+ "What's the biggest U.S. export to Japan?" 	
  \_|    |      + "Bullshit.  It makes the best fertilizer for their rice"