greg@vertical.oz (Greg Bond) (04/15/88)
As the title suggests, this is a feature I would like to see in unix. (Yes, let's change the world...) Under Netware on PCs, the command cd ....\run is equivalent to cd ..\..\..\run but much easier to think and type. (NB: on DOS '\' is path specifier, not '/') This generalises: . = current dir, .. = parent dir, ... = grandparent etc. This could be done in the shells (but only in restricted cases, similar to ~expansion). It would more usefully be done in the kernel routine (namei?) that maps names to inodes (where the symbolic links are traversed). Do others like this? Has anyone done it? I would guess that the code is simple. Greg. -- Gregory Bond, Vertical Software, Melbourne, Australia ACSnet: greg@vertical.oz, UUCP: uunet!vertical.oz!greg Gad! Did *I* start those lightbulb jokes?
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/19/88)
In article <75@vertical.oz> greg@vertical.oz (Greg Bond) writes: >As the title suggests, this is a feature I would like to see >in unix. If you mean the operating system sold by AT&T it's UNIX. Fair enough? >(Yes, let's change the world...) Not so fast, see below. >Under Netware on PCs, the command > cd ....\run >is equivalent to > cd ..\..\..\run >but much easier to think and type. >(NB: on DOS '\' is path specifier, not '/') > >This generalises: . = current dir, .. = parent dir, ... = grandparent etc. > > [text deleted] >Do others like this? It's ok. I like the / or \ as a separator to help parse the dots. ... is already used by some applications under UNIX. Changing something like this at this point is almost impossible but you are free to do so if you have access to source code. You should ask the Free Software Foundation folks, they might consider it for GNU (their UNIX like operating system). -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (04/19/88)
In article <75@vertical.oz> greg@vertical.oz (Greg Bond) writes: |This generalises: . = current dir, .. = parent dir, ... = grandparent etc. | |This could be done in the shells (but only in restricted cases, |similar to ~expansion). It would more usefully be done in the kernel |routine (namei?) that maps names to inodes (where the symbolic links |are traversed). The beauty of the current implemenetation is that the file system does most of the work. That is, the files '.' and '..' are really there. ANY process can make use of those files. You can always put the files '...' and '....' in there if you wish. True - this would need some sort of kernel mod if you wanted mkdir(2) to automagically add those files. I think there are better ways of being lazy - myself. Csh example 1: alias '..' 'cd ..' alias '...' 'cd ../..' alias '....' 'cd ../../..' Csh example 2: use cdpath set cdpath = ( .. ../.. ../../.. ) then when you type cd a the system will check for ./a ../a ../../a ../../../a Quote for the day: "If's you're lazy, don't modify the kernel' :-) -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
eichin@athena.mit.edu (Mark W. Eichin) (04/19/88)
In article <75@vertical.oz> greg@vertical.oz (Greg Bond) writes: >This generalises: . = current dir, .. = parent dir, ... = grandparent etc. >... . It would more usefully be done in the kernel >routine (namei?) that maps names to inodes (where the symbolic links >are traversed). ... >Gregory Bond, Vertical Software, Melbourne, Australia >ACSnet: greg@vertical.oz, UUCP: uunet!vertical.oz!greg Side note: Athena runs 4.3BSD + NFS (U Wisconsin merge, VS2/VS2000 workstations). Directories . and .. are what you'd expect (current dir and parent). If however you attempt to create/use a file named ... you have problems[1]. If such a file exists, readdir will return it, but stat of it returns ENOENT. If you try to create such a file, it will appear not on the remote filesystem, but in the local one, in the directory that the filesystem is mounted over[2]. Under the 4.3BSD+NFS on our IBM PC/RT workstations, ... works fine. Anyone else seen this bug? It has been reported and filed here, I don't know how far the report would have gone though. Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker'' [1] The name can be anything matching the regexp \.\.\.* (string of three or more dots.) This also is only valid for the top-level directory of a mounted filesystem. [2] In the Athena environment, this is nasty, as mount usually is preceded by mkdir, and thus umount is followed by rmdir. If the rmdir fails (ENOTEMPTY) due to a ... file, certain importing programs will detect the mount point, and report an error rather mount over existing files.
kutz@bgsuvax.UUCP (Kenneth Kutz) (04/19/88)
In article <75@vertical.oz>, greg@vertical.oz (Greg Bond) writes: > Under Netware on PCs, the command > cd ....\run > is equivalent to > cd ..\..\..\run > but much easier to think and type. > (NB: on DOS '\' is path specifier, not '/') > This generalises: . = current dir, .. = parent dir, ... = grandparent etc. > Do others like this? Has anyone done it? I would guess that the code > is simple. Modify mkdir. This would seem to be only a matter of creating a third link (in addition to the 2 that get created now "." and "..") which would be "..." for grandparent etc. This would require extra directory entries for the newly-created entries, one for each "parent" directory that exists. Where do you stop though? All the way to the root directory? There's nothing special about . and .. There just directory entries with the same inode number (links) to another directory entry. -- -------------------------------------------------------------------- Kenneth J. Kutz CSNET kutz@bgsu.edu UUCP ...!osu-cis!bgsuvax!kutz Disclaimer: Opinions expressed are my own and not of my employer's --------------------------------------------------------------------
matt@oddjob.UChicago.EDU (Not the kind you have to wind up on Sunday) (04/20/88)
In article <1934@bgsuvax.UUCP> kutz@bgsuvax.UUCP (Kenneth Kutz) writes:
) Modify mkdir.
) This would seem to be only a matter of creating a third link (in addition
) to the 2 that get created now "." and "..") which would be "..." for
) grandparent etc. This would require extra directory entries for the
) newly-created entries, one for each "parent" directory that exists.
So in directory /usr/users/matt/stuff I do "mkdir junk". Quick,
what's the inode number for "....." in junk?
This is a bad idea all around. Features for user convenience belong
in the shell. Features from programmer convenience belong in a
subroutine library.
Matt Crawfordkutz@bgsuvax.UUCP (Kenneth Kutz) (04/20/88)
In article <14678@oddjob.UChicago.EDU>, matt@oddjob.UChicago.EDU (Not the kind you have to wind up on Sunday) writes: : In article <1934@bgsuvax.UUCP> kutz@bgsuvax.UUCP (Kenneth Kutz) writes: : ) Modify mkdir. : ) This would seem to be only a matter of creating a third link (in addition : ) to the 2 that get created now "." and "..") which would be "..." for : ) grandparent etc. This would require extra directory entries for the : ) newly-created entries, one for each "parent" directory that exists. : This is a bad idea all around. Features for user convenience belong : in the shell. Features from programmer convenience belong in a : subroutine library. mkdir(2) system call. Not mkdir(1). -- -------------------------------------------------------------------- Kenneth J. Kutz CSNET kutz@bgsu.edu UUCP ...!osu-cis!bgsuvax!kutz Disclaimer: Opinions expressed are my own and not of my employer's --------------------------------------------------------------------
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/20/88)
In article <1934@bgsuvax.UUCP> kutz@bgsuvax.UUCP (Kenneth Kutz) writes: >This would seem to be only a matter of creating a third link (in addition >to the 2 that get created now "." and "..") which would be "..." for >grandparent etc.... >There's nothing special about . and .. There just directory entries >with the same inode number (links) to another directory entry. There is something very special about "." and "..". Programs that traverse directory trees know not to get into infinite loops by traversing "." and ".." also. If there were a third hard link called "...", such programs would loop endlessly unless they were modified. Consider "rm -r subdir", for example. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
tim@introl.uucp (Tim Chase) (04/20/88)
In article <4221@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >The beauty of the current implemenetation is that the file system >does most of the work. That is, the files '.' and '..' are really >there. Unfortunately, the non-beauty of many current implementations is that the "." and ".." are finding their way into kernel now that we have things like rename(2) and chroot(2). I think the functionality of these, and other, new functions is worth it and may provide some precedent for things like the "..." suggestion. Maybe now that knowledge of "." and ".." is both in the file system and the kernel, they ought to be removed from the file system. That would at least save some disk space, but would probably break programs that read directories. -- UUCP: {uunet,uwvax!uwmcsd1}!marque!introl!tim Phone: +1 414 276-2937
oosten@dutinfd.UUCP (Gertjan van Oosten) (04/21/88)
Why do some of you want to add extra inodes for ... .... etc.?
This could give you some trouble, like "File System Full"....
What I mean is: where do you stop? Do you just want an entry for ...
or also one for .... (okay, one more for the road: .....)???
Aha, I hear you say, let's stop at the number of dots that would lead
us to the root directory ('/' or '\', whatever).
But here comes the big one:
I want to be able to do "cd ...." in the root directory and still
end up in the same root directory!
(BTW: Novell Advanced NetWare lets you type "cd...." with the same
meaning, no space!)
The solution to all this is:
do NOT create new inodes for ... etc.
You don't need direct links to grandparent directories, great-grandparent
directories, ..., because these links are already available via ../..,
../../.., ... . What I really want is the command interpreter to recognize
things like "cd ..." and treat them as cd ../.. .
Now, was that so hard??
P.S. I like typing cd... far better than cd ..\.., simply
because them backslahes tend to crawl all over those
PC-keyboards (where is it now? Oh, to the left of the
shift key; no wait, it's next to the Esc :-) ).rbj@icst-cmr.arpa (Root Boy Jim) (04/23/88)
I think there are better ways of being lazy - myself. Me too. Csh example 1: alias '..' 'cd ..' Even better: alias .. 'cd ../\!*' That way, "cd /usr/bin; .. ucb" gets you to where rlogin lives. Quote for the day: "If's you're lazy, don't modify the kernel' :-) Yeah, adb it :-) Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement What's the MATTER Sid?.. Is your BEVERAGE unsatisfactory?
rbj@icst-cmr.arpa (Root Boy Jim) (04/23/88)
From: Tim Chase <tim@introl.uucp>
Unfortunately, the non-beauty of many current implementations is that "."
and ".." are finding their way into kernel now that we have things like
rename(2) and chroot(2). I think the functionality of these, and other,
new functions is worth it and may provide some precedent for things like
the "..." suggestion.
Maybe now that knowledge of "." and ".." is both in the file system and
the kernel, they ought to be removed from the file system. That would
at least save some disk space, but would probably break programs that
read directories.
Not so! While `.' could possibly be removed from the file system (but then
how would you remove a file called `-r'), the kernel has only partial
knowledge of `..'. All it knows is when to manipulate it in special cases,
such as mkdir, rmdir, and rename; and when to treat it specially, at
mount points, the root, and when chroot'ed. One might argue that this info
could be stored in the inode itself, and this might indeed be plausible.
UUCP: {uunet,uwvax!uwmcsd1}!marque!introl!tim
Phone: +1 414 276-2937
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
I'd like MY data-base JULIENNED and stir-fried!bin@rhesus.primate.wisc.edu (Brain in Neutral) (04/23/88)
From article <13087@brl-adm.ARPA>, by rbj@icst-cmr.arpa (Root Boy Jim): > > Not so! While `.' could possibly be removed from the file system (but then > how would you remove a file called `-r')... Probably with "rm - -r".
ekrell@hector.UUCP (Eduardo Krell) (04/24/88)
In article <13087@brl-adm.ARPA> rbj@icst-cmr.arpa writes: >While `.' could possibly be removed from the file system (but then >how would you remove a file called `-r') The kernel, or more specifically namei(), doesn't actually open the directory to look for "." in a filename like "./-r". It knows what the current working directory is (it's in the user block) and it uses that instead of looking for a "." entry. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
tim@introl.uucp (Tim Chase) (04/24/88)
In article <13087@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >Not so! While `.' could possibly be removed from the file system (but then >how would you remove a file called `-r'), the kernel has only partial You could still use "rm ./-r". I believe the system from which I am posting this (an Apollo 3010) doesn't have "." and ".." in the file system, but they (. and ..) seem to work as expected in all cases (so far). >knowledge of `..'. All it knows is when to manipulate it in special cases, >such as mkdir, rmdir, and rename; and when to treat it specially, at >mount points, the root, and when chroot'ed. Exactly. Now that the kernel is giving semantics to those filenames, it seems that those names don't really have to appear anywhere. Certainly there's no "/" lying around. I'm not advocating removing them, though, just pointing out that it is possible to. I still like the illusion of "everyting's in the file system and the kernel doesn't care what names you place there. -- UUCP: {uunet,uwvax!uwmcsd1}!marque!introl!tim Phone: +1 414 276-2937
hermit@shockeye.UUCP (Mark Buda) (04/25/88)
In article <911@dutinfd.UUCP> oosten@dutinfd.UUCP (Gertjan van Oosten) writes: > > Why do some of you want to add extra inodes for ... .... etc.? > This could give you some trouble, like "File System Full".... > > What I mean is: where do you stop? Do you just want an entry for ... > or also one for .... (okay, one more for the road: .....)??? > > The solution to all this is: > do NOT create new inodes for ... etc. I thought this was comp.unix.wizards! :-) You wouldn't be creating new inodes for ... .... etc. You would be adding directory entries. Unless you've got REALLY deep nesting levels, you wouldn't be taking up any extra space most of the time, anyway. (BSD disk block fragmenting intentionally ignored here.) Say you've got a SysV system. 1K disk blocks. 14-character filenames limit you to .............., incidentally. So you won't be adding more than 12 entries anyway. Only 3/8 of your directories will end up with an extra block tacked on, assuming the number of files in a directory is a random number. Less than that, even. It's a stupid idea, anyway. And this is a stupid comment. I just wanted to point out that it wouldn't involve any extra inodes. Hmmm... except that the root directory would be pretty huge. Especially on a BSD system with 256-character filenames or whatever it is. Gee, it would be something like 64K. .,..,...,....,.....,......,.......,........,....... you get the idea. -- Mark Buda / Smart UUCP: hermit@chessene.uucp / Phone(work):(717)299-5189 Dumb UUCP: ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!chessene!hermit Entropy will get you in the end. "A little suction does wonders." - Gary Collins
dg@lakart.UUCP (David Goodenough) (04/26/88)
From article <319@rhesus.primate.wisc.edu>, by bin@rhesus.primate.wisc.edu (Brain in Neutral): > From article <13087@brl-adm.ARPA>, by rbj@icst-cmr.arpa (Root Boy Jim): >> >> Not so! While `.' could possibly be removed from the file system (but then >> how would you remove a file called `-r')... > > Probably with "rm - -r". Or if the current directory is foo: rm ../foo/-b OOPS :-) That requires that .. still exist. Oh dear, can't have it all ways! However this suggestion that ... be a synonym for ../..: could it be implemented in the kernel? I mean, who turns a path name into an i-node number anyway? -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!adelie!cfisun!lakart!dg +-+-+ | +---+
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/26/88)
In article <911@dutinfd.UUCP> oosten@dutinfd.UUCP (Gertjan van Oosten) writes: > (BTW: Novell Advanced NetWare lets you type "cd...." with the same > meaning, no space!) That you can do easily, as a command, shell script, or function. Guess we don't have to rewrite the kernel after all (:-) -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mouse@mcgill-vision.UUCP (der Mouse) (04/27/88)
In article <4221@vdsvax.steinmetz.ge.com>, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: > In article <75@vertical.oz> greg@vertical.oz (Greg Bond) writes: >> This generalises: . = current dir, .. = parent dir, ... = grandparent etc. >> This could be done in the shells [...]. It would more usefully be >> done in the kernel routine (namei?) that maps names to inodes (where >> the symbolic links are traversed). > The beauty of the current implemenetation is that the file system > does most of the work. That is, the files '.' and '..' are really > there. Only sort of. .. must be special-cased to make it work properly across mount points, and I would be surprised to find that . is not special-cased. A dozen bytes of code in the kernel is cheaper than actually going to the disk to follow . when you see it. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
mouse@mcgill-vision.UUCP (der Mouse) (04/27/88)
In article <1934@bgsuvax.UUCP>, kutz@bgsuvax.UUCP (Kenneth Kutz) writes: > In article <75@vertical.oz>, greg@vertical.oz (Greg Bond) writes: >> This generalises: . = current dir, .. = parent dir, ... = grandparent etc. > Where do you stop though? All the way to the root directory? Certainly. Where else? > There's nothing special about . and .. There just directory entries > with the same inode number (links) to another directory entry. . can be, but .. can't: consider mount points. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
mouse@mcgill-vision.UUCP (der Mouse) (04/27/88)
In article <368@inta1.UUCP>, tim@introl.uucp (Tim Chase) writes: > Maybe now that knowledge of "." and ".." is both in the file system > and the kernel, they ought to be removed from the file system. Yes! Unfortunately, the information currently associated with .. must reside on disk somewhere, though it needn't be a regular directory entry. > That would at least save some disk space, Not enough to matter, I expect. 24 bytes per directory isn't much, and since we have to save the parent inumber anyway, it's only 20 (22?) bytes per directory. > but would probably break programs that read directories. Depends on how sloppily the program was written. Does the ignore . and .. or does it ignore the first two entries? Anybody know (a) how many directory-reading programs there are and (b) how many of these just ignore the first two entries instead of doing it right? der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
seth@violin.columbia.edu (Seth Robertson) (04/28/88)
Everyone writes (paraphrased): why don't you use ... for ../.. and .... for ../../.. Come on guys!! Don't all of you put your less reputable files into ... so it is more hidden? Most people, when they are incountered with . .. ... will just ignore the ... Of course anyone very knowledgeable about unix (or someone who runs du) won't be fooled, but it helps a little... -seth seth@ctr.columbia.edu sjr@cunixc.columbia.edu
greg@vertical.oz (Greg Bond) (04/29/88)
People have been arguing whether you need inodes, dir slots etc to
implement this solution. My thoughts when I proposed this was that
the implementation would be effectivly a text substitution, in the
way as symbolic links can be thought of as "replace the path up to
this point with the value of the link". Or, replace '...' with
'../..' (for as often as '...' appears). This would be a very small
change in one routine that parses pathnames. Nothing else need know
of it, as the rest of the kernel gets '../..', and problems with
backing past / are dealt with as now. Nor would existing directory-
reading routines or programs break, because the directory hasn't
changed. (Did you rewrite all your applications because symbolic
links aren't real links?)
Why in the kernel? Because this shorthand can then be used in all
situations, e.g. within editors, or arguments like "cc -I..../incl",
where shell name globbing won't touch them. How often have you cursed
that ~/dir/file from within programs or to args doesn't work?
Not to mention the kludge of forking a whole shell to glob ~ filenames.
--
Gregory Bond, Vertical Software, Melbourne, Australia
Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net)
UUCP: {uunet,pyramid,mnetor,ukc,ucb-vision}!munnari!vertical.oz!greg
ACSnet: greg@vertical.ozvic@zen.UUCP (Victor Gavin) (04/29/88)
In article <1083@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <368@inta1.UUCP>, tim@introl.uucp (Tim Chase) writes: >> Maybe now that knowledge of "." and ".." is both in the file system >> and the kernel, they ought to be removed from the file system. > >Yes! Unfortunately, the information currently associated with .. must >reside on disk somewhere, though it needn't be a regular directory >entry. Well HP on their series 500 (RIP) didn't use a normal file structure. They used a format that they had been using for many years: SDF (Structured Directory Format). This used entries in the inode for the current directory and parent directory. We used several of these beasties over many years. We ported many public domain utilities/games/programs. In that time I do not remember any problems caused by this difference. HP fixed possible problems wrt `.' and `..' by treating them specially in the kernel so that the calls ``did what was expected''. Only my uninformed opinion. vic ps Why do you have to be super-user to link directories? -- Victor Gavin Zengrange Limited vic@zen.co.uk Greenfield Road ..!mcvax!ukc!zen.co.uk!vic Leeds LS9 8DB +44 532 489048 England