ccplumb@watmath.UUCP (01/01/70)
Myself, I prefer the Unix-like single-root system. Just because Unix can't handle removable media is no reason not to be able to use Unix-like syntax and variable-position mounting in AmigaDOS. If I 'mount /dev/df1 /fish103', eject the disk, then try to do something with /fish103/unix/README (you didn't know there was a full 4.3 Unix on disk #103, did you? :-)), it can just pop up a requester: ------------------------- | Please insert disk | | "Fish 103" | | (mounted on /fish103) | ------------------------- The syntax conventions don't preclude removable media. Each AmigaDOS device can still interpret paths within itself as it wishes. Thus, I could use /dev/con/10/10/200/200, /dev/inet/[whatever goes here], etc. Only disk-like devices need support mounting. As to implementaton, hm... Essentially, you'd need some system for marking certain directories as being link points to certain devices. The Unix method is to set a bit in the inode telling the system to have a look through the mount table. A good way would probably to create a special sort of file which contains a pointer to the device mounted here. mount would create the file and unmount would delete it. The only other change required would be a change in the syntax AmigaDOS eats. While you were at it, you could implement . and .. - not as links, but simply as special strings recognized by the filename parser for disk-like devices. (There really isn't any need to have them present in the directory. All that does is adds special code to find and its relatives. ".." is already hard-coded into Minix (in the code which handles "cd .." across mount points). Probably Unix, too. I can't *really* tell how this could be integrated into AmigaDOS. I'm not too familiar with AmigaDOS innards - its ugliness (e.g. BCPL) has prevented me from learning about it. -- -Colin Plumb (watmath!ccplumb) HELLO, everybody, I'm a HUMAN!!
peter@sugar.UUCP (Peter da Silva) (09/21/87)
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. - It allows alien file systems to be easily grafted in. It's not clear to me that //machine/pathname is preferable to machine:path. - UNIX is based on a model where devices are relatively static. The AMIGA, as a floppy bades system, has to deal with volumes that pop in and out of the file system. How would you deal with this setup with UNIX file names? COPY is in c:, on device WorkBench: source file is in SomeFloppy: destination is in AnotherFloppy: copy somefloppy:source anotherfloppy:destination. [requester asks you to insert device somefloppy] [you insert somefloppy in df1:] [requestor asks you to insert device anotherfloppy] [you insert anotherfloppy in df0:] [grind grind grind] copy somefloppy:anotherfile anotherfloppy: [requester asks you to insert device workbench] [you insert floppy in df1:] [requester asks you to insert device somefloppy] [you insert somefloppy in df1:] Note: you never have to mount a file system. You don't have to prepare anything. You just swap disks. I would like to see the content of the disks themselves become more unix-like. Right now there is no satisfactory naming convention for the current directory. It's too easy to accidentally pop up a level. Concept UNIX AmigaDOS current directory . <null> file in current directory file file ./file <no equivalent> parent directory .. / 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. Solution: Adopt UNIX-style path names within the device. / becomes the root of the curent device. ./ becomes the current directory. ../ becomes the parent directory. /.. is a synonym for /. A file name may be preceded by a device name, in which case the path is relative to the root of the named device. 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". dev:df0/path would be equivalent to df0:path. In fact, you could even implement UNIX-style pathnames via dev:... just have it return locks and the like correctly. Then you could "cd dev:" and find yourself in a UNIX-style homogenous filesystem. You just couldn't create files in "/". It'd be rather like OS/9. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged yUUUUUfordputiDe
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/21/87)
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
bryce@hoser.berkeley.edu (Bryce Nesbitt) (09/21/87)
--- In summary, the file system definition needs: --- A way to specify the "current dir". "." or "::" or something better. When a disk with a duplicate name to a current device or assigned name is inserted, a requester with a string gadget should inform the user of the conflict, and force a new name to be selected before use of the disk is allowed. Moving up with "////" should top out at the root, without error. 1/2 :-) ------------------ read the rest for the reasoning... 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. > >[Why that suggestion got that response and description of a "problem"] >Solution: > Adopt UNIX-style path names within the device... > [much more deleted] Let's not and say we didn't. Taking a working file system and changing the namespace years after it's release does not sound like much of a win. Seriously, there are people who are used to the *Amiga* and not UNIX. Crazies who don't habitually type ".." or expect to go to the root with "/". >It's too easy to accidentally pop up a level. Only if you perform an incomplete UNIX <=> Amiga context switch. (Argh! ban the pun! ban the pun!) The functionality difference in this proposal is slight, and debatable at that. The asthetic difference is up to the user. I think "/" is a perfectly intuitive way of going up a directory. I *much* prefer this to "../". And going up multiple levels makes sense, "///". The only change I would make is to "top out" at the root, so "/////" would be the same if you are only two levels deep. (That is a preference... don't take that a serious suggestion.) I used MS-DOS and UNIX long before I heard "Amiga", so it's not my religious upbringing. --------- >Right now there is no satisfactory naming convention for the current directory. A-men! (To continue the religious slant :-). This would be a very sensible addition. The contenders are: "." Because UNIX uses it "::" Sort of makes sense. ":" is the root and it avoids adding *another* magic character that might need to be escaped. -- The other problem has to do with duplicate device/disk/assigned names. Pitty the poor artist who names a disk "FONTS:" I'd also separate assigned names and devices... but that's sticky internal design issue I'm not going to touch with a 25 foot telephone cord keyboard extension cable. |\ /| . Ack! (NAK, ENQ, SYN) {o O} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U How can you go back if you have not yet gone forth?
kim@amdahl.amdahl.com (Kim DeVaughn) (09/26/87)
In article <2388@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > > I think the solution for this could be adding logical links to AmigaDOS. > In the above case, something like: > > 1> MakeLink "." "" > 1> MakeLink ".." "/" I like the idea Dave! It has the side benifit of being able to control program execution based on argv[0], also (e.g., like compress/uncompress does in the UNIX(R) environment). Of course one can use aliases and option flags to achieve a similar effect, to a certain extent. Then all that's left is to fix up "ls" with a -a flag, and teach it not to display names that begin with a leading "." (or trailing .info) unless the flag's on ... /kim P.S. And instead of MakeLink, how about just "ln" ... :-)! -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
mph@rover.UUCP (Mark Huth) (09/26/87)
Has anyone else run into the following bug?(limitation) The copy command only accepts pathnames upto some length (I think it is 47 characters, but don't remeber offhand) With a hard disk I find that I often exceed this in an absolute pathname. Software that executes the copy command revealed this prpblem. I had to figure out the directory name and do an assign to it, then call the copy command with the pathname = TDEV1:filename. What a pain. Mark Huth
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/26/87)
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
cc1@ucla-cs.UUCP (09/28/87)
Don't hit 'n' yet :-) On unix's "" == current dir: I was BITTEN, badly by this bug once. On V7, I ran a set-uid program as root (set-uid ignored), and got to a place where it unlink()'d a file, name of file was a name given earlier. I had hit enter (I was testing to see how well it worked for boundary cases). Imagine my suprise when it couldn't find the directory again. Incidently, on system 3/5, "" is NOT current dir, its an error. No such file or directory, I believe (Don't ask me to create a "" entry). And yes, a////b does work correctly. I think this is the most uniform way of having a file system--the invariant is that you can always add "/" to a file to check for a directory, and you can always add "/file" to a directory to make a path. Now, why does this cause device drivers trouble? (I haven't written one yet) Michael The opinions represented here are a result of being educated at a school that discriminates againts roosters. Only the birds are responsible.
daveh@cbmvax.UUCP (Dave Haynie) (09/29/87)
in article <537@rover.UUCP>, mph@rover.UUCP (Mark Huth) says: > Summary: Bug?? in copy command > > Has anyone else run into the following bug?(limitation) > The copy command only accepts pathnames upto some length (I think it is > 47 characters, but don't remeber offhand) > > Mark Huth I haven't seen that one yet, but there are certainly some other limitations in pathname length lurking in there somewhere. Many of these may be based on who's handling that name. For instance, if I were to take an ARP Copy command replacement, the arguments would have no inherent string length limitations, as these are C-style, NUL terminated strings. The current AmigaDOS command was written in BCPL, and as such you'd expect a string limitation of 255 somewhere, either as an argument limit or a command line length limit. BCPL strings consist of a BYTE length followed by the characters of that string. Obviously if you're going to allow the empty string, then BCPL strings can't ever get longer than 255 characters a piece. I'm not sure what kind of limitations this has on the rest of the system, perhaps not many (assuming most things are in C). There's no inherent limits on the filesystem pathname, even though BCPL strings are used. This is because, when you are at the Packet levels of DOS and you want to obtain a lock, you make a packet that has a lock on the parent directory and a BCPL string to the file/directory you're after. This implies a maximum file/directory name length of 255, but these are limited much more by other things. Since you never really have to have more that one BCPL file name in a string at a time, there should be no absolute limit on path names. If you bump up a level and use dos.library, I'm not sure what to expect. Most dos.library calls (e.g. Open(), Lock(), ChangeDir()) accept full path names, but at least from C these look like C strings. Since most programs in are written in Assembler or C, I'd expect the most common DOS path limits to take after the limits inherent in dos.library calls, if any. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "God, I wish I was sailing again" -Jimmy Buffett
childs@cadnetix.UUCP (David Childs) (09/30/87)
In article <5218@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike Meyer) writes: <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 <<the name of the current directory... but it's not the recommended way of addressing <<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. [LOTS OF STUFF] <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. [LOTS OF STUFF] It seems to me that the problem isn't all that hard to fix. Why not just have all non-NULL UN*X directories end with '/', and all non-NULL AmigaD*S directories end with either ':' or '/'? Then insted of adding '/filename' to the directory name, one just adds 'filename'. This way, the NULL directory will work if all other directories end with '/'. I've allways thought it was a kludge to append a '/' to the directory name before adding the filename. By adding a slash first, one is admitting that the directory name should really be 'dir/' insted of just 'dir', or that the filename should really be '/filename' insted of just 'filename'. NULL, df0:, df0:dir/etc/, dir/ and / should all be valid directory names. I would have to say the biggest kludge is either operating system allowing a directory name that can't just have a filename appended to it. This is just my opinion, but it's the right opinion. I like sending stuff like this, it lets me see that I'm not the only one reading it. David Childs Cadnetix Corp. childs@cadnetix.UUCP seismo!hao!ico!cadnetix!childs P.S. I can't believe that ASDG will sell me an un-populated board for only $325, or what ever their price is. Let's see, I can take my $425 2 meg board, send it to them with $325, and get a 2 meg board back. What was that address again? :-) I'm sorry, it just doesn't seem like a real bargain. Id rather take my chances with the $45 converter card that lets me plug my SOTS ram into the 2000 bus. The other real bargain I've heard about over the net is ethernet card for $699 (I think) plus the $200 software to get ethernet (total $899), versus the Amiga2000 (if you have one approach) where you buy the IBM-PC bridge card plus an IBM-slotted ethernet card plus a development environment for $200 more than the first approach. How much IBM-PC compatibility do you get from the Amiga ethernet card? :-) I think the whole idea of the bridge card was to get a bus for inexpensive add-ons while getting a nearly free IBM-PC development environment to boot. Send Flames, Software at Cadnetix has a air-conditioner that could turn the Astrodome into a walk in freezer.
dave@csustan.UUCP (10/01/87)
In article <8365@shemp.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes: >On unix's "" == current dir: >I was BITTEN, badly by this bug once. On V7, I ran a set-uid program as >root (set-uid ignored), and got to a place where it unlink()'d a file, >name of file was a name given earlier. I had hit enter (I was testing >to see how well it worked for boundary cases). Imagine my suprise when >it couldn't find the directory again. ... > Michael Most likely the program stuck the current working directory onto the beginning of the path to unlink. (i.e. cwd + "" = cwd). While I am here, some people were saying that they liked device naming conventions like "<dev>:<path>" rather than having the devices mounted into the file system. For example, mount <dev>: as /games, then access it with "/games/<path>". I wonder if the people who liked "<dev>:<path>" were, in a past life, MeSsed up DOS users. We tend to prefer things that we are familiar with ... BTW, the OS could be set up so that a floppy would (optionally) be automatically mounted in some default path. This would make the mounting process (more or less) transparent to most users. Device independance is a VERY powerful concept! David "MS/DOS, just say no!" -- ----- David J Wells lll-crg!csustan!dave dave@csustan.uucp
flaps@utcsri.UUCP (10/06/87)
In article <> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >> 1> MakeLink "." "" > >P.S. And instead of MakeLink, how about just "ln" ... :-)! One reason is because Manx f---ed up and used "ln" rather than "ld" for their link command. But I agree that "MakeLink" is a little wordy. I think that the original unix "ln" / "ld" command names was insufficiently thought out. ajr
daveh@cbmvax.UUCP (Dave Haynie) (10/12/87)
in article <5495@utcsri.UUCP>, flaps@utcsri.UUCP (Alan J Rosenthal) says: > > In article <> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >>> 1> MakeLink "." "" >> >>P.S. And instead of MakeLink, how about just "ln" ... :-)! I called it "MakeLink", in keeping with the (admittidly wordy) syntax of AmigaDOS CLI commands, like "MakeDir". Or maybe it should be called "MakeLn". UNIX calls it "ln", Apollo's Aegis OS calls it "crl". I don't really care what it's called, but it's so useful, I want it. The Apollo situation is more like what we'd have on the Amiga, since UNIX supports both hard links and soft links, while Apollo only does soft links. Given the current Amiga file structure, only soft links would be possible to add in. The problem is that each file or directory in the Amiga file system directly knows who it's parent is. But logical links should be relatively simple to drop in, in an upward compatible fashion. > ajr -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat