Xref: utzoo comp.sys.att:2016 comp.unix.questions:4976 comp.unix.wizards:6014
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!bingvaxu!leah!itsgw!steinmetz!dawn!stpeters
From: stpeters@dawn.steinmetz (Dick St.Peters)
Newsgroups: comp.sys.att,comp.unix.questions,comp.unix.wizards
Subject: Re: Non-standard shell and su.
Message-ID: <8400@steinmetz.steinmetz.UUCP>
Date: 7 Jan 88 22:47:03 GMT
References: <200@icus.UUCP> <264@ho7cad.ATT.COM> <8389@steinmetz.steinmetz.UUCP> <6974@brl-smoke.ARPA>
Sender: root@steinmetz.steinmetz.UUCP
Reply-To: dawn!stpeters@steinmetz.UUCP (Dick St.Peters)
Organization: General Electric CRD, Schenectady, NY
Lines: 27

In article <6974@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>[quote of my warning about how ksh's cd behaves with symlinks]
>Lots of other shells behave this way; ours for example.
>
>I doubt that many scripts really would plan on the 4.3BSD /bin/sh
>behavior occurring in such a case.  Far more likely, they're
>expecting the behavior of ksh or the BRL Bourne shell.

I beg to differ, but we'd have to count them all to prove who's right.

Problems likely to be more common than the one I originally cited are
that under ksh
	cd <symlink>
	ls ../foo
always gives "../foo not found".  Also,
	if [ -f ../foo ]
always yields false.

Both these results are as described even if both a real ../foo exist
and a <back up the symlink>/foo exist.  These are not unlikely things
to find in scripts, and this behavior badly limits the usefulness of
symlinks, which are extremely useful if your shell behaves.
--
Dick St.Peters                        
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa              
uunet!steinmetz!stpeters