Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!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
Message-ID: <5218@jade.BERKELEY.EDU>
Date: Sat, 26-Sep-87 05:53:33 EDT
Article-I.D.: jade.5218
Posted: Sat Sep 26 05:53:33 1987
Date-Received: Sun, 27-Sep-87 10:32:07 EDT
References: <503@louie.udel.EDU> <1929@umd5.umd.edu> <775@sugar.UUCP> <5176@jade.BERKELEY.EDU> <805@sugar.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 167

In article <805@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<In article <5176@jade>, mwm@eris (Mike Meyer) writes:
<> Peter gave a nice little table of concepts and how you expressed them.
<> But he made a few mistakes. Let's correct them:
<
<That's not a bug, that's a feature. Sure, UNIX allows you to use "null" as the
<name of the current directory... but it's not the recommended way of addressing
<it. It's a side effect. It (as you pointed out) can't be used reliably anywhere
<dot can. Before you comment on this, read on...

Ah SO! The light dawns. Peter and I have different interpretations of
the Unix file name semantics. He says that "null is a kludge, as it
means the current directory everywhere but the beginning of a path
name." I says "/ is a kludge, as it means look in the current
directory for the following file name everywhere but the beginning of
the file name." This explains the differences in the table, and some
other things.

Note that we agree on the semantics, but disagree on how they should
be interpreted. Peter's way leads to a nicer system ("/file" appended
to a directory name always means find "file" in the directory); mine
is modelled after the source code.

That this double interpretation can happen at all is a sign that
something is fundamentally broken in the Unix file name mapping.
Possibly it's that a null directory name isn't an error.

<> 	either a file in dir, or a file in the root directory if dir
<> 	is null.
<
<I don't think that you would ever be using null as the name of the current
<directory unless you have a bug somewhere.

Same logic applies to AmigaDOS, so you should be able to drop it's
version to be the same as the Unix version. In fact, that logic is
even stronger in AmigaDOS, because a "null" directory name isn't
innocuous.

<The basic point I was making is
<that in UNIX you can *always* take a valid directory name and add "/file"
<to it to make a valid file name.

True, but only because the null directory means "wherever you are when
you got to this in the parse", so that "//file" is the same as
"/file". I.e., the accident (your word) of null directories working
the way they do make this work.


<In AmigaDOS you have to parse the name, and
<if the name is the current directory or the root you don't put the slash in.
<The parsing is trivial in 'C', but I'd hate to try to do it in a shell
<script. And a number of programs don't parse it right.

But if you use the "null" current directory in Unix, it breaks also!
That half the problem is fixed by providing a real name for the
current directory. Or at least as fixed as it is for Unix.

Someone suggested ";" as a good name for the current directory. Bad
move, as that's the start comment character in the CLI. Given the rest
of the system, I'd be tempted to suggest backslash. But the Unixphiles
will probably want ".". No problems with it, it's just that it's used
in file names a lot already.

<Also, why do you say "../" is the real name of the parent directory? It is
<a valid directory name, and you can always add "/file" to it, but it's not
<the simplest form of the name.

Because the Amiga DOS parent is "/", and you can just add the file
name to it. I was trying to make the Unix & AmigaDOS columns have the
same semantics - at least where possible.

<> 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.
<
<I am. It would remove one of the two cases where you can't just add "/file"
<to get a valid file name. Putting in a name for the current directory would
<remove the other. If you're going to do this then why not go all the way
<to the much simpler UNIX syntax.

This doesn't work on other devices, and will give fits to some
drivers. And you may want those programs to be able to use device
drivers (conman being the one that leaps to mind).

In other words, you then translate the problem from "Is this the root
of the device" to "is this the root of a device that handles null
first components correctly"? The first is trivial to find out; the
second can change on you between accesses of the same file name.

<> <[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.
<
[I moved this to this context; it seemed to fit better - mwm]
<You obviously use AmigaDOS more than UNIX. I use them about half-and-half.
<I prefer the UNIX naming convention because it's easier to not break things.

I would have said you obviously use unix more than AmigaDOS. I
actually use them close to half-and-half, leaning more towards Unix
than the Amiga if you start counting closely (I *don't* kind now, when
I'm mostly letting my Amiga paly terminal as "using AmigaDOS"). I can
see that the differences is in internalizations of the file system
semantics (some day, I'll find the *exact* wording I want for this
concept!).

<I don't do much of either, myself. What I find myself doing is passing
<null strings to programs expecting them to treat them as the name of
<the current directory (seeing as I don't have any better way of doing
<this), and having them blindly add a "/file" because null doesn't have
<a colon in it.

I've never run into that problem. Then again, I don't *ever* use null
as a valid file name on Unix. Except when the "/" key bounces :-).

<NULL is a bad name for the current directory. On UNIX it means "either
<the current directory or the root, depending on context". On the Amiga
<it means "either the current directory or the parent directory, depending
<on context". If you're in the root, it's not even legal in some contexts.

I agree. But once you turn that off, being able to append "/file" to
directory names to get valid file names quits working for Unix. Works
exactly the same for AmigaDOS, though.

<That's another thing... since we're changing things around why not switch
<to conventional directories with the file names in them? I don't know
<any other modern system that uses hashed directories (abominations like
<the ComputerVision mini and the Sperry-I-mean-Unisys 1100 don't count).

My sources tell me that MACH now does. What you really want (I assume)
to say is that you don't know of any modern system that doesn't keep
file names in the directory structure.

To get really scared by file systems, go take a look at some of the
oddities done in Xerox PARC. "Directory structure? Don't need it on my
disks."

<I realise there are a few programs that should break... but most of them seem
<to be fast-directory-listers that were writtent to take care of the warts
<in the current system. If you were doing this you would need to write and
<distribute an alternative to disksalv, of course.

To drag in the LEOS file system discussion, the *reason* that most
things wouldn't break is because the details of what directories look
like are hidden by Examine/ExNext. Unless you think you're IBM, and
know exactly what directory features users want, you should encourage
people to use ExNext/Examine for any future file system.

[On the DEV: device.]

My fault - I misread what you wanted it to do. Now that I understand
it, I like it. Gee, just think what

	dir dev: opt a

could do for you. Especially if you've got locks on a dozen disks
still floating around....

	<mike

--
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