lvc@tut.UUCP (10/22/87)
All this discussion of getting rid of . and .. is pretty
amusing. Just in case some of you are serious, here is a
good example of another use of it.
for p in $x/*/.
do
stuff
done
p will only take on values of executable directories (with /.
appended). This is easier than the alternative of letting p
range over all of $x/* and then testing if it is the name of
an executable directory. Also, sometimes $x/* will expand
to too many characters and the script could fail. There are
other uses of . than meaning the current directory.
Larry Cipriani tut!lvctrt@rti.UUCP (Thomas Truscott) (10/24/87)
The infamous "." and ".." have infested our file sytems for far too long. They are cute, yes, but so was Gizmo. We all know what "." and ".." mean, and so does UNIX. Making them directory entries gives us a crutch, but also hobbles us and blurs our view of the one true pathname. They are a blot on all directory traversal programs. They mock our beloved dot-files, bringing grief to those who do ".*". They litter the file system, out numbering the directories themselves! And riddle me this: why does an empty directory have two entries? There is, quite simply, no good reason for them to darken our directories. Consider yon shell script: > for p in $x/*/. > do > stuff > done Is not $x/*/ shorter of breath yet fully as noble of purpose? But supposing we wish to permit this folly, could not the mighty shell, defender of SIGSEGV, deign to look for "." and ".." as even now it looks for "/"? Is this so great a price, when the humble chmod chown cp csh diff du ls rcp rm tar find uusnap must all stand watch for the mocking entries, lest they be locked within those lurking links? What is the cost? A mere trifle. The odd pathname matcher will need enlightment, as must the handful of programs who foolishly skip the first two directory entries. What is the gain? Enlightenment itself, for a heavy burden will indeed lift. Morn not for "." and ".." for as they cast off their wordly trappings they will be reborn, fresh in meaning and pure in concept. Tom Truscott
frank@wacsvax.UUCP (10/29/87)
In article <648@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >All this discussion of getting rid of . and .. is pretty amusing. Just in case >some of you are serious, here is a good example of another use of it. > for p in $x/*/. > do > stuff > done >p will only take on values of executable directories (with /. >appended). This is easier than the alternative of letting p >range over all of $x/* and then testing if it is the name of >an executable directory. Please flame me if I am wrong but why wouldn't : for p in $x/*/ do stuff done be sufficient. I don't believe the . is necessary. However, don't take this an argument for doing away with . and ..! Frank O'Connor Computer Science University of Western Australia
chris@mimsy.UUCP (Chris Torek) (10/30/87)
In article <722@wacsvax.OZ> frank@wacsvax.OZ (Frank O'Connor) writes: >Please flame me if I am wrong but why wouldn't : > for p in $x/*/ > do > stuff > done >be sufficient. ... Well, for one thing, this uses the zero-length-string file name (right there after the second slash: it refers to the current directory as of that slash). If System V's namei is consistent, this will fail in the same way as open("", 0) (and it will not accept names like a//b or //x). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jfh@killer.UUCP (The Beach Bum) (11/03/87)
In article <9171@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <722@wacsvax.OZ> frank@wacsvax.OZ (Frank O'Connor) writes: > >Please flame me if I am wrong but why wouldn't : > > for p in $x/*/ > > do > > stuff > > done > >be sufficient. ... > > Well, for one thing, this uses the zero-length-string file name > (right there after the second slash: it refers to the current > directory as of that slash). > > If System V's namei is consistent, this will fail in the same way > as open("", 0) (and it will not accept names like a//b or //x). > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) > Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Sorry to do this to you Chris, but that works just fine here. I don't have sys/nami.c (or whatever the new name is) in front of me, but my understanding of what is going on is this: namei (func, mode) char (*func) (); int mode; { int c; c = (func) (); /* test for c == 0 to set u.u_error = ENOENT, or make current inode == root inode or current directory inode. */ do if room left insert character in u-page dirent structure. while ((c = (func) ()) != '/' && c != 0) while ((c = (func) ()) == '/' && c != 0) toss character out because it was just a /. /* at this point, c is '\0' or first char in next path name. */ /* go look in current directory for an entry that matches. */ /* if c == 0, return the current i-node, else go back. */ } Okay. Did anyone not know this already? Now, my understanding of the original bug was if the first `c' was '\0', the current I-node, which was the current directory, since c != '/'. That's why "" == . in the old world. Consider "/", where the first character returned is '/', and after that, the next is '\0'. The test, if I understand, and unless you have the sources, (which I don't, so I don't know ...), only happens that one time. A much better test is if u.u_dent.d_name[0] == 0, and return ENOENT. But '/' is still quite special ... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (11/04/87)
Frank O'Connor writes: > Please flame me if I am wrong but why wouldn't : > for p in $x/*/ > do > stuff > done > be sufficient. I don't believe the . is necessary. However, don't > take this an argument for doing away with . and ..! > > Frank O'Connor Actually the problem seems to be in the shell and not the os. In the Bourne shell on my SVR2 AT&T 3B5 */ expands to literall */ However, in the Korn shell on the same machine */ expands to f1/ f2/ ... fn/ Where f1 f2 ... fn are the names of *files and directories* in . Using csh under BSD */ expands to only directory names (at least on the Pyramid machine I'm writing this on). I wrote this short C program: #include <sys/types.h> #include <sys/stat.h> main(argc, argv) int argc; char *argv[]; { register int i; struct stat stbuf; for (i = 1; i < argc; i++) if (stat(argv[i], &stbuf) == -1) printf("cannot stat '%s'\n", argv[i]); } Under BOTH BSD and SVR2 I ran it with arguments of filename/ or directoryname/ the stat succeeded. So it seems the os doesn't give a toot if there is an extra slash or not. Same result if you use open instead of stat (of course). Now whether or not the shell should expand */ to include only directories I don't know. It might would be useful. I can mention this to Dave Korn as a suggestion for ksh if you want. Larry Cipriani tut!lvc
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (11/04/87)
In article <9171@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: ... > If System V's namei is consistent, this will fail in the same way > as open("", 0) (and it will not accept names like a//b or //x). ... SVR2 (and any AT&T Unix system I'm familiar with) lets you use multiple /. //a is the same as /a a//b is the same as a/b This nice thing about doing it this way is that you can be a little sloppy in your program and it will still work. I admit it I'm lazy! And what is the harm anyway? Perhaps in some situations a // indicates a broken program. Another case of damned if you do and damned if you don't. Larry Cipriani tut!lvc
snoopy@doghouse.gwd.tek.com (Snoopy) (11/12/87)
In article <972@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >SVR2 (and any AT&T Unix system I'm familiar with) lets you use >multiple /. > > //a is the same as /a > a//b is the same as a/b > >This nice thing about doing it this way is that you can be a little >sloppy in your program and it will still work. I admit it I'm lazy! >And what is the harm anyway? The harm is that this is not portable. With UTek's DFS, //a refers to the root directory on a machine called 'a'. I've seen articles indicating that Apollo's multi-machine file system (whatever they call their version) uses the same syntax. (Is anyone familiar with Apollo out there?) Sloppy programming is not a good idea. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
rengland@mntgfx.mentor.com (Richard England) (11/13/87)
in article <9363@tekecs.TEK.COM<, snoopy@doghouse.gwd.tek.com (Snoopy) says: < < In article <972@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: < <>SVR2 (and any AT&T Unix system I'm familiar with) lets you use <>multiple /. <> <> //a is the same as /a <> a//b is the same as a/b <> <>This nice thing about doing it this way is that you can be a little <>sloppy in your program and it will still work. I admit it I'm lazy! <>And what is the harm anyway? < < The harm is that this is not portable. With UTek's DFS, //a refers to the < root directory on a machine called 'a'. I've seen articles indicating < that Apollo's multi-machine file system (whatever they call their version) < uses the same syntax. (Is anyone familiar with Apollo out there?) < < Sloppy programming is not a good idea. < < Snoopy < tektronix!doghouse.gwd!snoopy < snoopy@doghouse.gwd.tek.com //a on an Apollo Domain network specifies a node name. Hence //a is a no-no. Both BSD and SYSTEM V Unix on a Domain network will recognize the node name so beware. Why not just stick to the published norms and be safe? -- ---------------------------------------------------------------------------- Rich England | "...Cock o' the North? Ach! Yon's a cheesey rengland@mntgfx.MENTOR.COM |tune. Weel no be playin' thaat tune!" ...!tektronix!sequent!mntgfx | Alec Guiness, "Tunes of Glory"
dce@mips.UUCP (David Elliott) (11/13/87)
In article <9363@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes: >In article <972@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >>This nice thing about doing it this way is that you can be a little >>sloppy in your program and it will still work. I admit it I'm lazy! >>And what is the harm anyway? > >The harm is that this is not portable. With UTek's DFS, //a refers to the >root directory on a machine called 'a'. I've seen articles indicating >that Apollo's multi-machine file system (whatever they call their version) >uses the same syntax. (Is anyone familiar with Apollo out there?) > >Sloppy programming is not a good idea. It's even more unportable, since the Apollo semantics differ when there are more than two slashes. That is //a means the root on machine 'a'. ///a means the same on the Apollo, but with DFS it means the same thing as /a. This allowed us to quickly fix sloppy code by changing sprintf's that use things like sprintf(path, "%s/%s", ...) to use //, though I think we tried to fix them all the right way. In addition, we changed the home of users like root to be "/.", so that programs that use "$HOME/path" wouldn't produce "//path" for root. I have mixed feelings about all of this, but I do hope that the V8 style (/n/host/...) will win out. -- David Elliott dce@mips.com or {ames,decwrl,prls}!mips!dce
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (11/14/87)
Summary: More on //a and a//b so n now if you are tired of this discussion. In article <9363@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: * In article <972@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: **SVR2 (and any AT&T Unix system I'm familiar with) lets you use **multiple /. ** ** //a is the same as /a ** a//b is the same as a/b ** **This nice thing about doing it this way is that you can be a little **sloppy in your program and it will still work. I admit it I'm lazy! **And what is the harm anyway? Please quote everything that is relevant to your reply, thanks. I also said that it might indicate you have a *broken* program. Broken also means non-portable (to me). I take a great deal of pride in my long lived programs and try to keep them as "clean" as possible. *Sloppy programming is not a good idea. Of course, but neither is going to great lengths to make a program "clean" that you are going to throw away in 10 minutes after your done writing it. If you ask me, I think the //a syntax to indicate the root file system on machine a is brain dead. Why not use a mount point instead of jerking around with //a ? Geez. Stupid programming is worse than sloppy programming. Larry Cipriani ...!cbosgd!cbsck!lvc AT&T Network Systems ...!cbosgd!osu-cis!tut!lvc Ohio State University Unix is a registered trademark of AT&T Bell Laboratories. AT&T is a registered trademark of American Telephone and Telegraph.
paul@umix.cc.umich.edu ('da Kingfish) (11/20/87)
In article <905@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >I have mixed feelings about all of this, but I do hope that the V8 >style (/n/host/...) will win out. (and someone else later opined that // for a root was a bad idea) we have apollos here, and they have // meaning the network root. for /n/host style names, we just mkdir /n, and create links in there, so that /n/fleetwood -> //fleetwood. that seems to work, althought i just did it quickly to see. myself, i like apollo and // because there are no mount points, or mounts to worry about. --paul -- Trying everything that whiskey cures in Ann Arbor, Michigan. Over one billion messages read.
jfh@killer.UUCP (11/24/87)
In article <2732@umix.cc.umich.edu>, paul@umix.cc.umich.edu ('da Kingfish) writes: > In article <905@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: > >I have mixed feelings about all of this, but I do hope that the V8 > >style (/n/host/...) will win out. > > (and someone else later opined that // for a root was a bad idea) > > --paul Urph - I copy the Same Old .cshrc file from one system to another. Last night I noticed that the /.cshrc file (for root) had the line set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin) Which is the path I've used for several years. What's going to happen to when I finally have the (mis)fortune to work on one of these network machines? - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 ...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243 "Don't Have an Oil Well? Then Buy One!" (214) 231-0993
dce@mips.UUCP (David Elliott) (11/25/87)
In article <2204@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: [discussion of network filesystem path preferences deleted] > >Urph - I copy the Same Old .cshrc file from one system to another. Last >night I noticed that the /.cshrc file (for root) had the line > >set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin) > >Which is the path I've used for several years. What's going to happen to >when I finally have the (mis)fortune to work on one of these network >machines? If the system administrator on the system has any kind of talent at all, you won't have to do a single thing! In other words, if it's misfortunate, it's application, not service, at fault. I use the same .cshrc and .login that I used before we had NFS or /n here, and I can continue to do so. As an example, we only have one copy of /usr/games on our Mips M-series BSD machines (on the host quacky), and everyone else has a symbolic link to /n/quacky/usr/games. When I rlogin to another machine and execute, for example, fortune, I get it. I don't have to change my path to include /n/quacky/usr/games. The biggest problems with network filesystems are not generally found at the user's level, they are in administration. -- David Elliott dce@mips.com or {ames,decwrl,prls}!mips!dce
andrew@frip.gwd.tek.com (Andrew Klossner) (12/02/87)
[]
"(and someone else later opined that // for a root was
a bad idea)"
"Urph - I copy the Same Old .cshrc file from one system to
another. Last night I noticed that the /.cshrc file (for root)
had the line
"set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin)
"Which is the path I've used for several years. What's going
to happen to when I finally have the (mis)fortune to work on
one of these network machines?"
If it's one of our systems, /etc/passwd will say that root's home
directory is "/." not "/", and everything will work just fine.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]