Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!sdcsvax!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: Re: Putting devices in the filename space (was Re: sources to dvi2iff...)
Message-ID: <5176@jade.BERKELEY.EDU>
Date: Mon, 21-Sep-87 01:24:58 EDT
Article-I.D.: jade.5176
Posted: Mon Sep 21 01:24:58 1987
Date-Received: Tue, 22-Sep-87 00:47:45 EDT
References: <503@louie.udel.EDU> <1929@umd5.umd.edu> <775@sugar.UUCP> <156@splut.UUCP> <783@sugar.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 127

In article <783@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<In article <156@splut.UUCP>, stu@splut.UUCP (Stewart Cobb) writes:
<>    And while we're at it, can we get rid of device names and go to a
<> single filesystem?  I have always hated this minor-but-annoying
<> difference between Amiga and UNIX.
<
<Let's not, and say we did.
<
<I used to really dislike the AMIGA-style method of having a dev:pathname, but
<it's grown on me.

I couldn't really decided between the two. I still can't. Meanwhile, I
agree with Peter. Let's not, and say we did. I want to work with it
some more.

<	- It allows alien file systems to be easily grafted in. It's not
<	  clear to me that //machine/pathname is preferable to machine:path.

Syntactic sugar(*). Why shouldn't /machine/pathname mean *exactly* the
same thing as machine:pathname? The current convention is "anything in
front of a ':' is a device name." The OS/9 convention is "the first
component of an absolute pathname is a device name." (caveat: I
haven't see the OS/9 networking, they may do something silly like
//machinename/pathname. I would expect either /machinename/pathname or
/net/machinename/pathname.) Since OS/9 can do it, AmigaExec can do it.

The current system means you get ":" for "top of the current
floppy/ramdisk/etc." You lose that, which is balanced against getting
":" back as a character in file names. On the other hand, you lose "/"
as the name of the parent directory. About which Peter says:

<	Adopt UNIX-style path names within the device. / becomes the root
<	of the curent device.

Let's not, and say we did.

Peter gave a nice little table of concepts and how you expressed them.
But he made a few mistakes. Let's correct them:

<
<	Concept				UNIX		AmigaDOS
<
<	current directory		.		<no equivalent>
					<null>		<null>
<	file in current directory	file		file
<					./file		<no equivalent>
<	parent directory		..		/
			should be	../, but...
<	root directory			/		:
<
<	Syntax		UNIX		AmigaDos
<
<	dir/file	a file in dir	either a file in dir, or a file in
<					the parent directory if dir is null
<					for current directory, or its
<					illegal if dir is the root directory.


That last one is a cheap shot, Peter. You know that the Unix version should
say:

	either a file in dir, or a file in the root directory if dir
	is null.

As for /dir being illegal in the root directory, that's because they
didn't put in the kludge that Unix has to map "parent of root" to
"root" in a file name. I'm sure that this could be done; I'm not sure
I want it to be done.

<[On AmigaDOS] It's too easy to accidentally pop up a level.

And on Unix, it's to easy to accidently wind up in the root. I find
myself doing "/name" on Unix to get to "../name" far more often than
the converse.

<Right now there is no satisfactory naming convention for the current directory.

And that's the only thing that's really a problem. Taking the Unix out
should work - have some name in the directory that points to the
directory itself. While that's being done, adding ".." to point to the
parent directory would probably make the Unixphiles happy. But only if
you call the current directory ".". The directory hashing might break
both of these things, though.

<Solution:

Obviously, I disagree with Peter's solution; or part of it. I used to
cuss at the "/ for parent directory" convention. Now I cuss at Unix
because it doesn't do thing that way. However, we *do* need a name for the
current directory.

<	Finally, implement DEV:. DEV: is a special device that takes its
<	first part of the file name and maps it to a device. This would
<	satisfy the people who want devices to be part of the file system.
<	Like me, on odd tuesdays.
<
<	Doing "list dev:" would be equivalent to "assign".

Wanting device names in the file system is something I do every once
in a while, too. DEV: looks like a nice way to do it, but I'm not sure
it can be made to work. For instance, while it's obvious what

	copy dev:df0 to vd0:copy-of-df0

does, I'd like to know what

	copy dev:pipe to vd0:copy-of-pipe

does? Likewise for dev:ram, dev:vd0 or dev:ser....

Can someone describe semantics for dev: for maximum usefullness?

<	dev:df0/path would be equivalent to df0:path.

If you can do that, can't you make dev:df0 equivalent to df0:? :-).
This is also something that has to be dealt with about the semantics
of dev:.

	<mike

(*) It's well known among language designers that syntactic sugar will
give you cancer of the semi-colon. :-)
--
Come all you rolling minstrels,				Mike Meyer
And together we will try,				mwm@berkeley.edu
To rouse the spirit of the air,				ucbvax!mwm
And move the rolling sky.				mwm@ucbjade.BITNET