> From: "Mark D. Roth" <[EMAIL PROTECTED]> > Date: Tue, 23 Jul 2002 22:02:53 -0500 > > On Tue Jul 23 13:31 2002 -0700, Paul Eggert wrote: > > I'd rather try $PWD, then pwd, and fall back on /bin/pwd only if the > > other two methods don't work. That way, the names will be nicer. > > That won't solve the problem, specifically because $PWD and pwd give > the "nice" path names. The problem is that ksh is trying to interpret > relative paths based on the string in $PWD rather than by actually > traversing the ".." links
OK, now I understand the problem. I also see that the problem occurs even in absolute path names. For example, with /bin/ksh on Solaris 8: 33-sic $ ls -ld /tmp/usr/local/src/dummy-0.1/../../common drwxrwxr-x 3 eggert eggert 183 Jul 24 01:54 /tmp/usr/local/src/dummy-0.1/../../common 34-sic $ cd /tmp/usr/local/src/dummy-0.1/../../common /bin/ksh: /tmp/usr/local/src/dummy-0.1/../../common: not found What a botch! > roth@coredump:/scratch/ac> head -1 usr/local/src/dummy-0.1/config.status > #! /bin/ksh > > Is this what you're seeing as well? No, mine uses /bin/bash and not /bin/ksh. This probably explains it. You don't have the SUNWbash package installed, so you don't have /bin/bash. However, I still don't like the solution of invoking /bin/pwd first, for the reasons I mentioned earlier. Why can't we fall back on /bin/pwd only if the current method fails? That way, only the poor ksh users will be stuck with the problems of ugly names and/or /bin/pwd failing.
