Date: Tue, 6 Nov 2007 11:52:52 -0500 From: Mike Meyer <mwm@mired.org> To: "Julian H. Stacey" <jhs@berklix.org> Cc: hackers@freebsd.org, Harti Brandt <harti@freebsd.org> Subject: Re: make: evaluation of symbolic link with ../ fails Message-ID: <20071106115252.1f97af6d@mbook.mired.org> In-Reply-To: <200711061620.lA6GKE8L090019@fire.js.berklix.net> References: <200711050002.lA502KUe064392@fire.js.berklix.net> <20071105085259.A39496@knop-beagle.kn.op.dlr.de> <200711061620.lA6GKE8L090019@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 06 Nov 2007 17:20:14 +0100 "Julian H. Stacey" <jhs@berklix.org> wrote:
> It seems to me that all except csh (including bourne shell !) are
> broken !! Amazing ! None of them cope properly actually following
> symbolic links, they all make false premise the /some_path/.. ==
> /some_path !
That's not a bug, that's a feature. When symlinks were introduced in
4.1c (or thereabouts), people were often surprised to do:
$ cd /some_path/child
$ ...
$ cd ..
and not wind up in /some_path, or having the ever popular sh loop:
$ for dir in <list of subdirs>
$ do
$ cd $dir
$ ...
$ cd ..
$ done
start working on something totally unrelated to the current directory
halfway through the loop. So sh (and etc.) added a feature so that
those things worked the way users expected them to.
Basically, the shells don't make a false premise that /some_path/.. ==
/some_path, they make the premise appear to be true as a feature.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071106115252.1f97af6d>