Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!uwvax!dogie!uwmcsd1!marque!uunet!munnari!mulga!ditmela!latcs1!vertical!greg
From: greg@vertical.oz (Greg Bond)
Newsgroups: comp.unix.wizards
Subject: Re: A suggestion: .... == ../../..
Message-ID: <91@vertical.oz>
Date: 29 Apr 88 08:34:57 GMT
References: <75@vertical.oz> <4221@vdsvax.steinmetz.ge.com> <1081@mcgill-vision.UUCP>
Reply-To: greg@vertical.oz (Greg Bond)
Organization: Vertical Software, Melbourne, Australia
Lines: 24

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