gmg@hcx.uucp (Greg M. Garner) (02/07/89)
Would it be possible to make the arp 1.3 CD command recognize the unix
directory names .. and . ? I would like to see the cd command go to
the parent directory anytime it saw a file name .. I realize that
this may seem like a kludge, but it could even check for a real
directory called .. before using the parent dir name. Since the arp
commands all use the arp.library, it seems to me that all the commands
(list, etc) could implement the .. stuff. Some rules that spring to
mind are:
1) If .. is specified, see if a .. file for directory exists. If it does
not, expand this into the / command.
2) If the path name is specified as ../name, then remove the ..
giving the desired action.
3) if the . is specified by itself, then replace this with ""
(or whatever is needed to make the dos stay in the same
directory).
4) If the path name is specified as ./name, then remove the
./ giving the desired action.
Does anyone else like this idea? I really like the way arp works now
with the *? wildcards, but I would like to see the above stuff added,
If this didn't introduce other problems I haven't thought about.
There are two reasons I would like to see this, one being that I am
used to doing .. in unix, and two being that some make files from the
unix world have the ../name construct embedded in them.
What do you think?
Greg Garner
501-442-4847
gmg@hcx.uucp USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmgjwright@atanasoff.cs.iastate.edu (Jim Wright) (02/13/89)
In article <1769@cveg.uucp> gmg@hcx.uucp (Greg M. Garner) writes: >Would it be possible to make the arp 1.3 CD command recognize the unix >directory names .. and . ? PLEASE!!! I rate the use of : for root directory, / for parent directory and "" for current directory as a leading contender for the worst Amiga feature (right up there with the bizarre wildcards). It makes as much sense as the MSDOS use of \ for a pathname seperator. Although I know the overwhelming weight of "existing stuff" seems to preclude this, I would really like to see AmigaDOS adopt sane filename and path naming conventions. (My wish for 1.4. :-)
perley@trub.steinmetz (Donald P Perley) (02/13/89)
In article <789@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: >In article <1769@cveg.uucp> gmg@hcx.uucp (Greg M. Garner) writes: >>Would it be possible to make the arp 1.3 CD command recognize the unix >>directory names .. and . ? > >PLEASE!!! I rate the use of : for root directory, / for parent >directory and "" for current directory as a leading contender for >the worst Amiga feature (right up there with the bizarre wildcards). >It makes as much sense as the MSDOS use of \ for a pathname seperator. > >Although I know the overwhelming weight of "existing stuff" seems to >preclude this, I would really like to see AmigaDOS adopt sane filename >and path naming conventions. (My wish for 1.4. :-) Try a shell. At least one commercial one (Tshell) lets you use unix file name conventions including .. for parent directory and / for root directory (thats file system root, not just for that drive). Disk drives and assignments are like partitions on the root directory, so c:whatever can be referenced as /c/whatever. Of course that only helps in cases where the shell gets to interpret the name (command lines and shell scripts). -don perley
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/14/89)
:In article <1769@cveg.uucp> gmg@hcx.uucp (Greg M. Garner) writes:
:>Would it be possible to make the arp 1.3 CD command recognize the unix
:>directory names .. and . ?
:
:PLEASE!!! I rate the use of : for root directory, / for parent
^ hate, I assume
:directory and "" for current directory as a leading contender for
:the worst Amiga feature (right up there with the bizarre wildcards).
:It makes as much sense as the MSDOS use of \ for a pathname seperator.
:
:Although I know the overwhelming weight of "existing stuff" seems to
:preclude this, I would really like to see AmigaDOS adopt sane filename
:and path naming conventions. (My wish for 1.4. :-)
When I first began programming on the Amiga, I had these same
feelings, but after using it for a while (and also using UNIX systems
extensively for many years), I find I like the Amiga filesystem
naming conventions better. NOT the wildcards though (I agree with you
there); Those are not a function of the filesystem anyway, but of the BCPL
programs.
'/' for parent directory is much more efficient than '../', ""
for the current directory is likewise more intuitive. I never did like
the fact that UNIX directories contained '.' and '..' (what a hack!). As
far as using ':' for the root of the current volume, that is also an
intuitive extension of the multiple-volume system considering that '/'
is already taken to mean parent directory.
-Mattcosell@bbn.com (Bernie Cosell) (02/14/89)
In article <8902131846.AA21527@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: } }:In article <1769@cveg.uucp> gmg@hcx.uucp (Greg M. Garner) writes: }:>Would it be possible to make the arp 1.3 CD command recognize the unix }:>directory names .. and . ? }: } }:directory and "" for current directory as a leading contender for }:the worst Amiga feature (right up there with the bizarre wildcards). ^^^^^^^^^^^^^^^^^ } } When I first began programming on the Amiga, I had these same }feelings, but after using it for a while (and also using UNIX systems }extensively for many years), I find I like the Amiga filesystem }naming conventions better. NOT the wildcards though (I agree with you }there); Those are not a function of the filesystem anyway, but of the BCPL }programs. I agree with your comments about '.' and '..' wholeheartedly (and was about to post a similar followup when I saw yours). BUT.. I think you've missed it with the wildcards. The UNIX 'wildcard standard' is just plain cretinous. You might ask why UNIX files follow an unbelivably cramped and unnatural 'extension' scheme . The primary answer is that because of the DUMB wildcard facility, you could not easily pick up all of the object files if the extension was a reasonable ".REL", or check out all the libraries if they were ".LIB" (whereas "*.o" and "*.a" _does_ work). It is a *real* loser that UNIX doesn't support full regular expressions in its filename matching. Now, if you're arguing that "#?" is common enough that it deserves some simple (= one-char) abbreviation, I could go with that, but even HINTING that UNIX's hopelessly limited scheme ought to be the exemplar is misguided, IMHO. If you wanted *my* wish for the 1.4 filesystem, I'd really like both hard- and sym-links. In fact, that mostly would make the '..' problem go away: you could just do "link -s / .." in any directory you care about (or make 'makedir' be an alias to do that for you automatically, which is **ALL** that unix does. '.' and '..' are ***NOT*** built inot the kernel!! --- with a bit of hackery, you can *remove* the '..' entry from a directory and everything works just fine, except that .. out of THAT directory doesn't!). __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
deven@pawl.rpi.edu (Deven Corzine) (02/14/89)
I still find some definite problems with the AmigaDOS method of file system structuring. I find "." and ".." far easier to use effectively, even if they are more to type. "" as current directory is obnoxious, if you ask me. There is no easy equivilent for "./file" under AmigaDOS... "file" isn't the same thing; maybe you want to force use of the file in the current directory, and not search any sort of a path. (Path searching should never be done on pathnames, only on basenames...) You can't use '""/file' or '"/file"' or '/file' because they all refer to the file in the parent directory. I suppose "current directory/file" would probably work, but that's a rather horrible kludge itself, and far far more inconvenient to type than ./file is. (You CAN, for example do 'list "current directory"' to get a listing of the current directory. weirdness.) Hence, I'd much rather have . and .., with / as root. A viable option is to provide both filenaming conventions, selectable by configuring an environment variable. (preferably not global) I don't understand at all the objection to Unix wildcards. Both the Bourne shell and C-Shell support somewhat more complex wildcards than the simple ? and * characters. Certainly on par with AmigaDOS's wildcards. In addition, the wildcards are expanded in the shell, and can therefore be used consistently, not just where the programmer decided to let you use wildcards. I strongly agree with the need for symlinks and hard links in AmigaDOS. Hard links, at least. As a point of note, Unix does NOT make a symbolic link to the parent directory under "..". By no means. ".." is a HARD link to the parent directory, and "." is a HARD link to the current directory. As such, "." is literally a subdirectory, though it is self-referential. And, um, excuse me, but if you think Unix wildcards are so limited that they can only handle "*.o" and "*.a" and not "*.REL" or "*.LIB" then you are a complete bozo. First off, Unix conventionally uses lower case, and the entire philosophy behind Unix supports effeciency and keeping things short and simple. (Granted, SysV and BSD 4.3, et al. are somewhat larger than they perhaps ought to be. But the idea remains.) This applies in part to filenames, mostly to save typing and to be consistent. Just because object files in Unix are normally such as "file.o" doesn't mean you couldn't use "file.obj" as well; it's just more to type, while .o is quite enough of a suffix to make it clear what type of file it is. A .obj extension might be handy for a neophyte who is unfamiliar with Unix, but merely hampers experienced users unnecessarily. Unix is harder to learn than many operating systems because of its terseness, but many people find they like it much better once they get used to it. I certainly do. Next time, please get your facts straight before flaming as fine an operating system as Unix is. Or hold your flames. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
bader+@andrew.cmu.edu (Miles Bader) (02/15/89)
jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: > PLEASE!!! I rate the use of : for root directory, / for parent > directory and "" for current directory as a leading contender for > the worst Amiga feature (right up there with the bizarre wildcards). > It makes as much sense as the MSDOS use of \ for a pathname seperator. I didn't like when I got my amiga either-- I was very used to unix. But now I find that it's actually a lot easier to use ('cause you you only need one character to go up a level). MsDos's '\' IS stupid because the '\' is hard to type on ibm keyboards. > Although I know the overwhelming weight of "existing stuff" seems to > preclude this, I would really like to see AmigaDOS adopt sane filename > and path naming conventions. (My wish for 1.4. :-) I think you're mistaking "sane" with "familiar"... I wouldn't be surprised if by the time 1.4 comes out you won't care anymore anyway... -Miles
bader+@andrew.cmu.edu (Miles Bader) (02/15/89)
cosell@bbn.com (Bernie Cosell) writes: > The UNIX 'wildcard standard' is > just plain cretinous. You might ask why UNIX files follow an > unbelivably cramped and unnatural 'extension' scheme . The primary > answer is that because of the DUMB wildcard facility, you could not > easily pick up all of the object files if the extension was a > reasonable ".REL", or check out all the libraries if they were ".LIB" > (whereas "*.o" and "*.a" _does_ work). It is a *real* loser that UNIX > doesn't support full regular expressions in its filename matching. What on earth do the extensions used for object (of COURSE, .rel stands for "object!") and archive files have to do with wildcards? *.rel and *.lib work just the same as *.o & *.a. > If you wanted *my* wish for the 1.4 filesystem, I'd really like both hard- > and sym-links. In fact, that mostly would make the '..' problem go away: you > could just do "link -s / .." in any directory you care about (or make > 'makedir' be an alias to do that for you automatically, which is **ALL** that > unix does. '.' and '..' are ***NOT*** built inot the kernel!! --- with a bit > of hackery, you can *remove* the '..' entry from a directory and everything > works just fine, except that .. out of THAT directory doesn't!). Definitely. Symlinks for 1.4 (pretty please...)! -Miles
brant@uf.msc.umn.edu (Gary Brant) (02/15/89)
[eat this] In article <cXy91wy00Uka8KLdxB@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: >> PLEASE!!! I rate the use of : for root directory, / for parent >> directory and "" for current directory as a leading contender for >> the worst Amiga feature (right up there with the bizarre wildcards). > >I think you're mistaking "sane" with "familiar"... > >-Miles As a sysnonym for the current directory, "" is an abomination. It must be escaped multiple times to get it past shells, source-level debuggers, etc. Using . would be at the same time familiar and sane. Arguments over whether the parent should be .. or / and whether the root should be : or / are of little interes; either is usable. However we *NEED* a sane synonym for the current directory. This is non-negotiable; "" MUST go. -Gary Brant ARPA: brant@uf.msc.umn.edu #include <std/disclaimer.h>
peter@sugar.uu.net (Peter da Silva) (02/15/89)
A dissenting view... [Matt Dillon prefers Amiga file naming conventions and hates the wildcards] I prefer the Amiga wildcards... they're a more complete regular expression syntax than UNIX's... but the file naming conventions are very hard to deal with. UNIX file names with an optional prepended device name would have been better. Best would be something like: //dev/path/file I'm currently using a network that uses this convention for remote file systems. It works rather well. [The original poster thinks the Amiga file names are the worst part of Amiga DOS] No, the gross misbehaviour of the Execute() call is. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
peter@sugar.uu.net (Peter da Silva) (02/15/89)
In article <35960@bbn.COM>, cosell@bbn.com (Bernie Cosell) writes: > You might ask why UNIX files follow an > unbelivably cramped and unnatural 'extension' scheme. Because the system was designed on 110-baud teletypes. > The primary > answer is that because of the DUMB wildcard facility, you could not > easily pick up all of the object files if the extension was a > reasonable ".REL", or check out all the libraries if they were ".LIB" > (whereas "*.o" and "*.a" _does_ work). So does *.REL and *.LIB. I really don't see what point you're making here. Personally I prefer to either say '.o' and '.a', or go all out and say '.relocatable' and '.library'. What's so special about 3 uppercase characters? > It is a *real* loser that UNIX > doesn't support full regular expressions in its filename matching. Yes, but the example you gave above doesn't demonstrate this. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
crooks@ingr.com (Steve Crooks) (02/16/89)
In article <35960@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes: >You might ask why UNIX files follow an >unbelivably cramped and unnatural 'extension' scheme . The primary >answer is that because of the DUMB wildcard facility, you could not >easily pick up all of the object files if the extension was a >reasonable ".REL", or check out all the libraries if they were ".LIB" ^^^^ ^^^^ >(whereas "*.o" and "*.a" _does_ work). Why couldn't you just say "*.REL" or "*.LIB"? I find that with combinations of ?, *, and [] that I have no problem matching with wildcards. . . . . . . -- --Steve Crooks ...uunet!ingr!crooks!crooks (UUCP) crooks!crooks@ingr.com (Internet)
peter@sugar.uu.net (Peter da Silva) (02/16/89)
In article <DEVEN.89Feb14055924@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) writes: > I don't understand at all the objection to Unix wildcards. Both the > Bourne shell and C-Shell support somewhat more complex wildcards than > the simple ? and * characters. Certainly on par with AmigaDOS's > wildcards. Not so. You can't, in UNIX wildcards, specify "all .o or .s files starting with "uk", "can", or "us", and an optional ".z". (the cshell bracket syntax is not a wildcard syntax... it's expanded before the wildcards are applied). On the Amiga you can specify: (uk|can|us)#?.(o|s)(|.z) The cshell (but not the bourne shell) will allow: {uk,can,us}*.[os]{,.z} But some results of {...,..} are surprising... > In addition, the wildcards are expanded in the shell, and > can therefore be used consistently, not just where the programmer > decided to let you use wildcards. This is nice, but an orthogonal issue. > I strongly agree with the need for symlinks and hard links in > AmigaDOS. Hard links, at least. As a point of note, Unix does NOT > make a symbolic link to the parent directory under "..". By no means. Symlinks would be easier, I think. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/17/89)
In <DEVEN.89Feb14055924@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) writes: >.... There is no easy equivilent for "./file" >under AmigaDOS... "file" isn't the same thing; maybe you want to >force use of the file in the current directory, and not search any >sort of a path. (Path searching should never be done on pathnames, >only on basenames...) You can't use '""/file' or '"/file"' or '/file' >because they all refer to the file in the parent directory. I suppose >"current directory/file" would probably work, but that's a rather >horrible kludge itself, and far far more inconvenient to type than >./file is. (You CAN, for example do 'list "current directory"' to get >a listing of the current directory. weirdness.) But "file" _is_ the same thing, only a lot more intuitive and shorter. Paths are searched _after_ the current directory, not before. >Next time, please get your facts straight before flaming as fine an >operating system as Unix is. Or hold your flames. It's always a good idea to get your facts straight, no matter which OS you are knocking, wouldn't you agree? -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (02/18/89)
In article <3439@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <DEVEN.89Feb14055924@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) writes: [ says Unix wild cards are just as good as AmigaDos's ] >Not so. You can't, in UNIX wildcards, specify "all .o or .s files starting >with "uk", "can", or "us", and an optional ".z". Yes, you can, and this is an example of the flexibility of expanding wildcards in the shell and passing them to programs as separate args: uk*.[os] can*.[os] us*.[os] uk*.[os].z can*.[os].z us*.[os].z >On the Amiga you can specify: > > (uk|can|us)#?.(o|s)(|.z) In this example, the Amiga syntax is certainly more consice and easier to understand, but there are examples that go the other way as well. For example, suppose you want to specify just the files foo, bar, and baz. In bourne shell syntax it's foo bar baz but in AmigaDos syntax you have to type foo|bar|baz which results in an undesired directory search, and many AmigaDos programs won't let you extend the above extension arbitrarily. I remember one time I was trying to copy several particular files from sys:c to ram:c and the AmigaDos copy command would only copy the first five matching files when I used the above syntax. I had to use multiple copy commands to get it done. This was partially because of a bug in that particular command's wildcard expander (which has been fixed, I beleive), but was compounded by the fact that most AmigaDos programs will only accept ONE single (possibly wildcard) argument as their file list. Here are some examples of things that just CAN'T be done with AmigaDos wildcards: dir1/foo dir2/bar dir3/baz dir1/foo dir2/foo dir3/foo dir[123]/foo */foo (and similar constructs using device/assign names rather than directories.) >> In addition, the wildcards are expanded in the shell, [ ... ] >This is nice, but an orthogonal issue. I disagree, it is a closely related issue, and certainly a more significant one. AmigaDos wildcard syntax is more general than that of Unix shells, but because it can only be used in more limited ways, it is less useful. AmigaDos wildcard "features" can be emulated on Unix, but not vice-versa. And on Unix it would take 5 minutes to modify the shell to use AmigaDos wildcard syntax and everything would work. Each user can choose a shell that uses the preferred syntax. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
peter@sugar.uu.net (Peter da Silva) (02/19/89)
Yes, you're right, having the shell do the wildcard expansion is superior. I never said anything else. BUT, given that, the Amiga wildcard *syntax* is a superset of the UNIX one. If you're going to write a shell for the Amiga, or do anything else, PLEASE use the Amiga syntax. That way you get the best of both worlds... -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
rusty@hocpa.UUCP (M.W.HADDOCK) (02/22/89)
In article <35960@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes: >I agree with your comments about '.' and '..' wholeheartedly (and was >about to post a similar followup when I saw yours). BUT.. I think >you've missed it with the wildcards. The UNIX 'wildcard standard' is >just plain cretinous. You might ask why UNIX files follow an It's not Unix per se just the shells so blame the [Unix] shell writers out there. Maybe the next new one will contain more regex parsing. Still, if you have the csh (or a derivative) or the ksh you've got the square brackets, [], though not just like egrep uses in that you can say ls [a-z]*[ab] The shell would catch "aa" or "n123b" but, unlike egrep(1), it wouldn't catch the filenames "b" or "a" now would it? And let's not forget the Curly Sisters, left { and right }, have been quite useful to me with the csh. Also, how would ^ and $ be used in parsing filenames??? If you say beginning and end of the filenames you already have it, albeit implicitly. All in all, I can live with the Unix shells' wildcards if you at least give me them Square Boys, [ & ]. The thing I don't like is the varying degrees to which regex is used. "awk"'s list is different from "ed"'s which is a subset of "vi" (some more modern versions of vi have + notation, which means 1 or more of the prefixed regex which has been more than handy) all the way "up" to GnuEmacs which has still more if not all known regex notations. I think I'd die if even just one itsy-bitsy, eeney-weeny portion of this world started becoming consistent with itself. [Heavy sigh.....] -Rusty- -- Rusty Haddock {uunet!likewise,att,arpa}!hocpa!rusty AT&T Consumer Products Laboratories - Human Factors Laboratory Holmdel, New Joyzey 07733 (201) 834-1023 rusty@hocpa.att.com ** Genius may have its limitations but stupidity is not thus handicapped.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (02/23/89)
In article <3434@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) presents a dissenting view to Matt Dillon's prefered Amiga file naming conventions: >.... UNIX file names with an optional prepended device name would have been >better. Best would be something like: > //dev/path/file Obviously, this is a religious issue, but I think an even better syntax could be borrowed from MIT's Project Athena, where they have a problem of potentially thousands of file systems that can be attached. The syntax could be: ~dev/path/file that is, a device (or ASSIGN name) would have a leading squiggle, and the example would be equivalent to dev:path/file. It's only one character longer and finesses many of the other syntax problems -- for example, to add a file name to a directory component, even if it is a device, just add a slash and the file name: "~dev" + "/" + "file" ==> "~dev/file" or "~dev/dir" + "/" + "file" ==> "~dev/dir/file". A file name beginning with a slash is relative to the current device; that is, "/a/path/name" is equivalent to "~curdev/a/path/name." It's simple and uniform. I won't argue whether Unix's "." and ".." should be used, although I do prefer them. I do think that "" for the current directory is not the best possible -- is ""/file a legal name? (I don't think so.) -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
w-colinp@microsoft.UUCP (Colin Plumb) (02/24/89)
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) wrote: > Obviously, this is a religious issue, but I think an even better syntax > could be borrowed from MIT's Project Athena, where they have a problem of > potentially thousands of file systems that can be attached. The syntax > could be: > ~dev/path/file > that is, a device (or ASSIGN name) would have a leading squiggle, and the > example would be equivalent to dev:path/file. How is ~dev better than dev:? The / vs. .. argument is independent. I have a paper here that's relavent, although I don't know where it comes from. Page 563 of something. "The Hideous Name" - Rob Pike & P.J. Weinberger, AT&T Bell Labs. Quotes: research!ucbvax@cmu-cs-pt.arpa:@CMU-ITC-LINUS:dave%CMU-ITC-LINUS@CMU-CS-PT -Carnegie-Mellon University mailer I cannot tell what the dickens his name is. - Shakespeare, Merry Wives of Windsor, II. ii. 20. They talk about the things that go in the Unix file name space - files (/u/colin/foo), devices (/dev/tty), processes (/proc/01234), faces (/n/face/research/pjw), connections to other processes (/dev/pt/pt04), and synonyms for other files (/dev/stdin). The latter lets the programmer forget about the - convention for file names. The last 4 are new to the Eighth Edition and more recent unices. The problem with different syntax for differnt parts of a name is that standard tools don't work so well. And that you can easily create things that are syntax errors. E.g. on the IBIS remote file system on 4.2BSD systems, you can use the ucbvax:file syntax. Okay, now whose shell can handle *:file? The eighth edition uses /n/ucbvax/file, and so /n/*/file is easy to understand. Or what about ucbvax:kremvax:file? Is this a syntax error, a request to talk to machine "ucbvax:kremvax", or a request for forwarding? They also roast RFC 822 and RFC 882 pretty thoroughly. "No one pays any attention to the standard as long as the software keeps delivering mail. This means that a mail transmitting program in practice must understand the details of local names outside its domain, to the extent that constructing a network mailer is a research topic in heuristic programming." I think the idea of mounting devices on each other is one of the great things Unix brought to the world. -- -Colin (uunet!microsoft!w-colinp) "Don't listen to me. I never do."
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (02/25/89)
In article <731@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >How is ~dev better than dev:? The / vs. .. argument is independent. Consistancy. Pathname components are separated by a slash. Always. Fully- specified path names begin with a squiggle. Always. For programming, there are fewer special cases or other corner cases that must be handled (such as C:/foo being illegal -- or is it?). Think of it as forest of filesystem trees, where the top-level "directory" is the current list of indirections. And for people who use csh, ksh, or later Bourne shells, the notation is intuitive, as the same syntax is used there for indirection (although the indirection is through the password file on the login name, of course). And, indeed, the / v. .. issue (I hope we're not arguing!) is somewhat orthogonal, although the consistancy principle implies that multiple slashes should be equivalent, else they become another special case. (But I can see how the rules would work; I'd just find them a little more complicated -- personal preference, again.) I could live with either; I'd rather not have to live with both -- my fingers keep forgetting on which system I'm typing..... >"The Hideous Name" - Rob Pike & P.J. Weinberger, AT&T Bell Labs. >research!ucbvax@cmu-cs-pt.arpa:@CMU-ITC-LINUS:dave%CMU-ITC-LINUS@CMU-CS-PT > -Carnegie-Mellon University mailer This is a mixed-mode mail address, not really relevant to the issue of file naming conventions. But it is a good example of how "simple" interactions can trip you up. >The problem with different syntax for differnt parts of a name is that >standard tools don't work so well. .... the ucbvax:file syntax. Okay, >now whose shell can handle *:file? .... This is my point. Separating the components with a slash buys consistancy. If the top-level "directory" looks enough like a real directory to a program it may not even need to be aware of the difference. Passing comment: As soon as UUCP/USENET get translated into Aztec C (or a portable subset), I'm planning to add this syntax to the transfer format. It's actually what's documented for UUCP transfers, and it will keep our HoneyDanBer UUCP from being too helpful and mangling the path names.... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
peter@sugar.uu.net (Peter da Silva) (02/26/89)
In article <731@microsoft.UUCP>, w-colinp@microsoft.UUCP (Colin Plumb) writes: > I think the idea of mounting devices on each other is one of the great things > Unix brought to the world. OS/9 took the idea to heart, though the developers wanted people to specify the device a file was on, as AmigaDOS does. Very simple syntax: /floppy/bin/sh. There was also a "/dev" pseudo device for character style devices. The "root" file system was not "really" there. The only problem you have with this is you can't say "the root of the current device". In practice, "//" as the "superroot" works ok. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
michael@stb.UUCP (Michael) (03/04/89)
In article <6001@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > [comparison of what can and can not be done in amigados/unix] > >Here are some examples of things that just CAN'T be done with >AmigaDos wildcards: > > dir1/foo dir2/bar dir3/baz > dir1/foo dir2/foo dir3/foo > dir[123]/foo > */foo > (and similar constructs using device/assign names rather > than directories.) ((dir1/foo)|(dir2/bar)|(dir3/baz)) dir(1|2|3)/foo dir(1|2|3)/foo #?/foo I think that anything you can do in unix I can do in AmigaDos. Try #(x/)foo to match foo, x/foo, x/x/foo, x/x/x/foo, x/x/x/x/foo, etc. in unix. Oh, you mean that about 1/2 of the commands that take wildcards will fail on my examples? Thats a different problem--the code should be written once in a library, not every time by different programs. Michael p.s. This is not ment as a flame; but don't say "You can't do this" unless you're really sure of it. : --- : Michael Gersten uunet.uu.net!stb!michael : crash!gryphon!denwa!stb!michael : Its not the Coff that carries you off, its the coffin they carry you off in.
rap@ardent.UUCP (Rob Peck) (03/07/89)
In article <10657@stb.UUCP>, michael@stb.UUCP (Michael) writes: > In article <6001@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > > [comparison of what can and can not be done in amigados/unix] > > > >Here are some examples of things that just CAN'T be done with > >AmigaDos wildcards: [ examples deleted ] Anyone who has problems with commands not supporting wildcards should look at (or just USE) the SPAT or DPAT scripts that are now in the S: directory for 1.3. The syntax is: SPAT <command-name> <wildcard-pattern> <other option(s)> or DPAT <command-name> <wildcard-pattern> <directory> <other-option(s)> These each run the named command once (in a script-directed loop) for each time a filename matches the wildcard string that you provide. Thus the file itself need never support wildcarding because it gets run perhaps many times, but each time receives only a vanilla (simple) file name. I especially like the alias assigned for the RENAME command (forgot if they used 're' or what, but essentially it lets you move a wildcard specified set of files from one directory to another in a single command invocation. Very nice. Just like Unix's mv dir1/dir2/dir3/* newdir The AmigaDOS equivalent uses DPAT... see the file S:Shell-startup for details. Rob Peck