If you try and run Mozilla from a symbolic link to <install_dir>/mozilla, then it fails to launch, because dist_bin is set incorrectly. This is true of every release up to and including 0.8.1. A patch to fix this is attached, and can also be found at: http://www.astradyne.co.uk/mozilla/mozilladiff.txt The patch has been tested on Red Hat Linux 6.2 and 7.0 and on Solaris 8. Patch follows: *** mozilla Sun Apr 1 16:42:08 2001 --- mozilla.orig Sun Apr 1 16:39:17 2001 *************** *** 32,53 **** #uncomment for debugging #set -x ! linkname="$0" ! ! linkchar=l ! while [ "$linkchar" = l ] ! do ! linkdetails=`/bin/ls -l "$linkname"` ! linkname=`echo "$linkdetails" | sed 's/.* //'` ! linkchar=`echo "$linkdetails" | cut -c1` ! done ! ! dist_bin=`dirname "$linkname"` ! ! unset linkchar ! unset linkname ! unset linkdetails ! script_args="" moreargs="" debugging=0 --- 32,38 ---- #uncomment for debugging #set -x ! dist_bin=`dirname $0` script_args="" moreargs="" debugging=0

This is definitely a problem. setting status to new.

--> build config i think would be a good place for this, cc leaf and granrose in case they are interested

Good idea but there seems to be some problems with the patch Relative links don't work: /usr/bin/mozilla -> mozilla-2001-03-31-21 /usr/bin/mozilla-2001-03-31-21 -> /usr/local/mozilla-2001-03-31-21/mozilla And can we trust that s/.* // will always work as expected? - spaces in names - can ls print trailing space?

There are a couple of problems with the patch. 1) spaces are allowed in file names so removing everything up to the last space won't always work. 2) dist_bin really should be canonicalized to eliminate such things as "./..///./foo" Consider something like: linkname=$0 while [ -L "$linkname" ] ; do linkname=`/bin/ls -l "$linkname" |sed -e 's/^.* ->//' \ |sed -e 's/^ *//'` done distbin=`dirname "$linkname"|sed -e 's/^ *//'` distbin=`(cd "$distbin"; pwd)`

For relative links that will still break. If linkname is relative you have to linkname="`dirname $oldlinkname`/$linkname" And for using "pwd" there is problem that it can resolv to a path that is not usable between multiple hosts in NFS environments assuming that dist_bin is shown to users or registered to somewhere.

I don't see the problem with dirname. I don't call it until I find somethign that's not a link. The NFS thing may well be a problem, though. Of course, relative paths are also a problem.

You have to call dirname in the loop if new linkname is relative. Example: /usr/bin/mozilla -> mozilla-zoo /usr/bin/mozilla-zoo -> /zoo/mozilla start: linkname=/usr/bin/mozilla, current directory is $HOME loop1: linkname=mozilla-zoo no more looping because there isn't mozilla-zoo in the current directory

Loop which works with relative links while [ -L "$linkname" ]; do dest=`/bin/ls -l "$linkname" | sed -e 's/^.* ->//' -e 's/^ *//'` if expr "$dest" : "\/" >/dev/null; then linkname="$dest" else linkname=`dirname "$linkname"`"/$dest" fi done

I'm stupid, I know, but I still don't see the problem. This little test script works for me. Can you give an example of how my script fails? #!/bin/sh linkname=$0 echo "|$linkname|" while [ -L "$linkname" ] ; do linkname=`/bin/ls -l "$linkname" |sed -e 's/^.* -> //' ` done distbin=`dirname "$linkname"` distbin=`(cd "$distbin"; pwd)` echo "|$distbin|" It's a little different because there's no way to deal with a leading space in a file name with just ls -l. It would be very nice if ls -Q were available. Since that can't be guaranteed, we'll just have to strip everything up to and including " -> " and assume the rest is a file name.

OK, I can't read what's infron of me. Sorry. I see the problem now.

*** This bug has been marked as a duplicate of 57866 ***

verified.