The script that starts mozilla assumes that you haven't symlinked to it. I've put all mozilla stuff into /usr/local/lib/mozilla, and put a symlink to /usr/local/lib/mozilla/mozilla into /usr/local/bin. I expect that typing 'mozilla' will make it start, but that is not the case. This patch makes the mozilla script smarter; it follows symlinks before trying to run run-mozilla.sh. Aw, heck. It's easier to include the whole 'mozilla' script than to make a patch: #!/bin/sh # # The contents of this file are subject to the Netscape Public License # Version 1.0 (the "NPL"); you may not use this file except in # compliance with the NPL. You may obtain a copy of the NPL at # http://www.mozilla.org/NPL/ # # Software distributed under the NPL is distributed on an "AS IS" basis, # WITHOUT WARRANTY OF ANY KIND, either express or implied. See the NPL # for the specific language governing rights and limitations under the # NPL. # # The Initial Developer of this code under the NPL is Netscape # Communications Corporation. Portions created by Netscape are # Copyright (C) 1998 Netscape Communications Corporation. All Rights # Reserved. # ## $Id: mozilla,v 1.8 2000/06/17 00:54:07 brendan%mozilla.org Exp $ ## ## Usage: ## ## $ mozilla [args] ## ## This script is meant to run the mozilla-bin binary from either ## mozilla/xpfe/bootstrap or mozilla/dist/bin. ## ## The script will setup all the environment voodoo needed to make ## the mozilla-bin binary to work. ## #uncomment for debugging #set -x dist_bin=`dirname $0` ### # Find out the name of this script: if [ "$dist_bin" != "." ]; then a="$0" else a=`which "$0" 2>&1 | head -1` fi # a is now the full and complete pathname to this program cnt=20 # While 'a' is a symlink, do: while [ -h "$a" ]; do # Decrement cnt; I'd use the bash math stuff, but it breaks on /bin/sh cnt=`awk 'BEGIN{print '$cnt'-1}'` # Quit if recursion has gone too far if [ $cnt -lt 1 ]; then echo Too many links break fi # Find the target of the symlink. Note: spaces not handled well c=`ls -ld $a | awk '{print $NF}'` # Absolute or relative symlink? case $c in /* ) a=$c ;; * ) a=`dirname $a`/$c ;; esac done dist_bin=`dirname $a` ### script_args="" moreargs="" debugging=0 MOZILLA_BIN="mozilla-bin" while [ $# -gt 0 ] do case "$1" in -p | -pure) MOZILLA_BIN="mozilla-bin.pure" shift ;; -g | --debug) script_args="$script_args -g" debugging=1 shift ;; -d | --debugger) script_args="$script_args -d $2" shift 2 ;; *) moreargs="$moreargs \"$1\"" shift 1 ;; esac done eval "set -- $moreargs" echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@" $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@"

Changing component over to XP Apps: Cmd-line Features. Changes look like they should work alright (untested), marking New.

Oops, forgot to check 'reassign bug'.

keyword magic. btw, this is not cmd-line features. And definately not XP, as this is linux only. This is probably build config I'd say. cc brendan, who is mentioned in the file.

cc cls, granrose says you are the right person

No, diff -u patches are better than whole files (why should everyone who doesn't have the script memorized have to detach the attachment and run diff by hand against the unpatched source?). Please attach one. /be

--- mozilla Wed Oct 25 13:32:36 2000 +++ /tmp/a Fri Nov 10 11:30:41 2000 @@ -33,6 +33,41 @@ #set -x dist_bin=`dirname $0` +### + +# Find out the name of this script: +if [ "$dist_bin" != "." ]; then + a="$0" +else + a=`which "$0" 2>&1 | head -1` +fi +# a is now the full and complete pathname to this program + +cnt=20 + +# While 'a' is a symlink, do: +while [ -h "$a" ]; do + # Decrement cnt; I'd use the bash math stuff, but it breaks on /bin/sh + cnt=`awk 'BEGIN{print '$cnt'-1}'` + # Quit if recursion has gone too far + if [ $cnt -lt 1 ]; then + echo Too many links + break + fi + # Find the target of the symlink. Note: spaces not handled well + c=`ls -ld $a | awk '{print $NF}'` + # Absolute or relative symlink? + case $c in + /* ) a=$c ;; + * ) a=`dirname $a`/$c ;; + esac +done + +dist_bin=`dirname $a` + +### + + script_args="" moreargs="" debugging=0

Reassigning to alecf. /be

comments on the patch: - need a better name for "a" questions for other shell hackers: - is there a better way to do the math besides awk? - is there a better way to follow the symlinks besides ls | awk? As to actually accepting this, I kind of feel like this is the purpose of MOZILLA_FIVE_HOME.. I'm not really sure that trying to find ourselves using 'which' is a productive (or secure) way of doing this.

Why can't expr(1) be used for math from a shell script? It predates awk. Didn't MOZILLA_FIVE_HOME get renamed to something better, recently? /be

I'm not in favor of having to set environment variables or modifying a shell script before you can successfully run a program. Call me old-fashioned or something. If you can find the pathname to the currently running shell script in a better (portable/secure) way, please do. And secure? If the command was run with a full pathname (the only secure way) then the full pathname shows up in $0. If the user relied on their path, then the full pathname doesn't show up in $0, and I figured we can use the path as well. I can't think of a situation where a hacker could exploit this, without replacing the 'which' command (or the 'ls' command, or the 'awk' command, or how about the 'sh' command). Instead of 'a', I guess you could call it 'tmp' or 'temporary_throwaway_variable'. And yep, expr would work for the math; I'd just overlooked it.

it's MOZILLA_HOME now

don't get me wrong, I agree that getting this right would be great.. I just want to do it the right way (if there is one) the issue with using 'which' that I had is that 'which' might not actually find the currently running script. can you attach an updated patch with the variable and expr fix?

This new patch is much improved. It doesn't use 'which', which barfs when ';' is in the name. It handles filenames with ' ', ';', '`' or ' -> ' in them, and probably all other special characters. It doesn't use awk; only dirname, expr and test. It can be confused if the target of the link contains ' $currentpath -> ', but solving that is hard. Possibly check for the existence of ' -> ' twice on the line and die with a warning? --- mozilla Wed Oct 25 13:32:36 2000 +++ ../src/mozilla Tue Nov 14 10:02:23 2000 @@ -32,7 +32,48 @@ #uncomment for debugging #set -x -dist_bin=`dirname $0` +dist_bin=`dirname "$0"` +### + +# Find out the name of this script: +if [ "$dist_bin" != "." ]; then + curpath="$0" +else + for testpath in `echo $PATH | tr : ' '`; do + if [ -x "$testpath/$0" ]; then + curpath="$testpath/$0" + break + fi + done +fi +# curpath is now the full and complete pathname to this program + +cnt=20 + +# While 'curpath' is a symlink, do: +while [ -h "$curpath" ]; do + cnt=`expr $cnt - 1` + # Quit if recursion has gone too far + if [ $cnt -lt 1 ]; then + echo Too many links + break + fi + # Find the target of the symlink. Filenames with ' $curpath -> ' in + # the target half not handled well; perl's minimally matching .*? needed. + c=`ls -ld "$curpath"` + d=`expr "$c" : ".* $curpath -> \(.*\)"` + # Absolute or relative symlink? + case "$d" in + /* ) curpath="$d" ;; + * ) curpath=`dirname "$curpath"`/"$d" ;; + esac +done + +dist_bin=`dirname "$curpath"` + +### + + script_args="" moreargs="" debugging=0

Reporter, please click the "create a new attachment" link instead of pasting your patches inline, thanks. alecf: mozilla0.6 is a compatibility release w/ netscape6.0 [which just hit rtm]. I suspect you meant mozilla0.9.

Ok, it's now an attachment.

moving a few 0.9 bugs out to 1.0 to lighten my 0.9 load.

*** Bug 74304 has been marked as a duplicate of this bug. ***

There are several problems. 1) comment says that curpath has "now the full and complete pathname" but thats not always true. Consider going to /usr/local and then running program bin/mozilla. 2) running ./mozilla causes PATH checks. It should not. 3) running "sh mozilla" causes PATH checks. It should not. 4) what about "::" in PATH or ":" at the start or at the end of PATH? 5) in "Too many links" we should call "exit" with error code, not "break" 6) in error conditions curpath is not initialized. Propably it would be better to check if curpath is set to something reasonable before and after loop. If it fails it should exit. 7) if d is empty we should exit with error message and code.

*** Bug 81792 has been marked as a duplicate of this bug. ***

I've been bitten by this once too often. Try the patch.

I dunno, this looks ok to me.. sr=alecf if cls or another unix guru (mcafee?) will review

It occurred to me that mozilla should honor MOZILLA_FIVE_HOME if it's already set in the user's environment. Here's a patch to do that. Does anyone use the Korn shell? My patch doesn't really address it. FWIW, the simplest way to test whether your shell's pwd is returning physical paths is: ln -s . foo sh -x 'cd foo; pwd' If the result containns foo, it's not.

You cannot test all the possible major shells. For example your patch doesn't work with HP-UX's posix shell /bin/sh as expected. I recommend hardcoding /bin/pwd instead of pwd if you want real path.

+# clean it up +dist_bin=`(cd "$dist_bin"; pwd )` And please, don't do this if you use MOZILLA_FIVE_HOME to set dist_bin.

If you hardcode a path you have to check if the file exists and is executable not to mention trying to figure out if it does what you think it does. You also override the user's PATH. The system pwd might be slow and the user might have her own version, not to mention the possibility that a fork and exec is expensive. That's one reason why shells have builtins. Now if HP-UX, or any other vendor platform, has some specific requirement then it should get a special startup script that is created at configure time. It will be happy, the rest of us will be happy, and we can all move on to something important. As for dist_bin=`(cd "$dist_bin"; pwd )`, that's in case MOZILLA_FIVE_HOME is a symlink.

If user or administrator sets MOZILLA_FIVE_HOME it should not be changed or made canonical. This is important for example in multihost environments which have shared disks. Then the shell and pwd. I don't think speed is the issue here. If you want to optimize mozilla script you should look other means than /bin/pwd vs. builtin pwd. Using /bin/pwd is not optimal solution at all but I think it it better than testing if you have bash or zsh and forgetting all other shells (sh, ash, ksh, posix sh, and their all vendor versions). There don't seem to be any common way to disable extensions for builtin pwd commands. Only "safe" solution seems to be /bin/pwd. The only real problem is what to do if it doesn't exist. And then there is the question do we really need to make dist_bin canonical?

BTW there is a bug in the patch. /z/yyy -> mozilla /z/mozilla This situation causes dist_bin to always be the working directory not the /z directory.

Here's how I've seen the problem with 'pwd' handled by SGI in one of their scripts in PCP: # determine path for pwd command to override shell built-in PWDCMND=`which pwd 2>/dev/null | $AWK_PROG ' BEGIN { i = 0 } / not in / { i = 1 } / aliased to / { i = 1 } { if ( i == 0 ) print } '` if [ "X$PWDCMND" = "X" ] then # Looks like we have no choice here... # force it to a known IRIX location PWDCMND=/bin/pwd fi

OK, how about a perl script? There are far fewer perl versions then shell versions.

Unfortunately many unix flavors don't have perl with the base operating system.

Here's an updated patch. I'll also attach a perl version of the script. There's really no way to win. "which" may be broken on some platform, awk may be gawk, or mawk, or nawk, or oawk, or whatever. Eventually you just have to stop trying to please everyone and do *something*. Oh well.

I've been thinking. IS it necessary to have absolute physical pathw or will absolute relative paths do? If relative paths are OK then I think this problem can be easily solved.

OK, one more shot at this.

OK, the shell scripts have been stable forever and I'll bet most people don't use the debugging stuff, so how about replacing the scripts with a real program. You trade one set of problems for another but it's faster and offers potentially better control. Patch upcoming. It's only tested on Linux and some of the environment variables aren't hooked up yet but it may be useful.

There are a few rude programs out there that just don't play nice on Unix. Among other things, they think they can put weird characters, like spaces, in file names. Mozilla is one of them. To chase symlinks robustly in a shell script means knowing how each platform's ls behaves with special characters in file names. It's also necessary to know which environment variables each ls honors. So, the startup script would have to know about all platforms and their quirks plus it would have to parse some number of environment variables, not to mention doing all this without depending on exactly which shell /bin/sh is. Unbelievably messy, and very slow. That's why I think a compiled program as a launcher is the way to go. In addition, it is much easier to do platform-specific tricks in a launcher than in mozilla itself. For example, take a look at bug 76968 which wants tilde expansion. If $HOME exists, that's fairly easy; if it does not then it gets messy. It would be much easier to just require $HOME to exist and let the launcher worry about it. It is much easier to find an expert who knows a particular platform than an expert who knows that plus all the mozilla arcana. In any event, I will attach a new version of a launcher. It's only been tested on Linux but fixing that shouldn't be too hard. It is also meant to be independent of the mozilla source tree so administrators can build it in the field if they wish. Changing title from "allow mozilla shell script to run from symlinks" to "allow mozilla to start from symlinks". Also pushing it out.

Taking it back.

An even better version.

Ok, my turn. This patch is based off of attachment 36135 [details] [diff] [review]. I removed the various checks for an internal pwd and just use /bin/pwd. I explicitly check for run_mozilla.sh when resolving symlinks. This allows the script to stop in the proper place so that you can run it from objdir/dist/bin without having to "install" Mozilla. If run-mozilla is not found, the script exits with an error. I think this patch should cover the various symlink issues mentioned earlier.

Bah. Forgot to regenerate the patch before attaching it.

Comment on attachment 72217 [details] [diff] [review] handle symlinks v2.1 Looks good to me.

Comment on attachment 72217 [details] [diff] [review] handle symlinks v2.1 a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk

Comment on attachment 72217 [details] [diff] [review] handle symlinks v2.1 This new patch looks like it can cause 7 or even more processes to be fork()ed at startup. Given how painful startup time is already, I think this patch could be optimized some. Specifically, couldn't $PWD could be used instead of /bin/pwd? Additionally, I suspect that dirname and basename can be emulated with 0 forks with clever field-separator ($IFS/$OFS) hacking. But maybe just incorporating all this code into the apprunner executable itself would be an even bigger win.

Oh bother. Does every /bin/sh set $PWD? Exactly how much of a delay do you expect those 7 fork()s to incur? (7 being the one external symlink case. The common case, run-mozilla.sh in the same dir as mozilla, would be 2.) Using a crude tool such as GNU time, I'm seeing a ~.03 sec delay for each _additional_ level of symlinks that need to be resolved on a P3-600. I'm willing to accept a .03s delay for using symlinks as opposed to symlinks not working at all. Sure, we could skip all of this scripting and leave it up to each mozilla-based application _and_ utilities to resolve this issue. Personally, I don't see the point given the number of programs that need to be modified. If you're going to travel down that road, you might as well just use -rpath and hardcode the location of the components dir in the app. Of course, then you'll lose the installation portability. But, I digress.

Atatchment 72217 has been checked into the 0.9.9 branch & the trunk.

Comment on attachment 72217 [details] [diff] [review] handle symlinks v2.1 My build currenty hangs in ./mozilla with 100% CPU load (ps doesn't show any other mozilla processes than the mozilla launch script running) This must have been caused by the new code in here :( Looking through the code trying to understand where this might come from, I didn't understand the following line: >+ until [ $found != 0 -a -L "$progname" ]; do What's that expression enclosed in [ ] meaning? Esp. the '0 -a -L "$progname"' part seems somehow strange to me...

REOPENing. If I go back to the "old" mozilla launch script (I just re-inserted the one line that was removed with the patch and commented out all inserted lines), the build runs like it should. If I use the "new" script, it hangs with 100% CPU as said above. My system is SuSE 7.3, kernel 2.4.18, KDE 2.2.2 /bin/sh is "GNU bash, version 2.05.0(1)-release (i386-suse-linux)"

more investigation: If I use the "new" mozilla launch script as it is in builds currently, and comment out the beginning and end of the "until" loop, it launches perfectly on "traditional" ./mozilla command. Somehow it seems we're getting an infinite loop here when the until loop is in the script.

likewise, my build also hangs. the problem is that progname is never set if run_moz is exists and is executable. this is the case for me, and therefore the "until" loop never ends :-( perhaps we should back this out??

Is this possibly responsible for todays blocker as well (bug 129075)?

just for the fun of it and different sh implementations: solaris sh says: + dirname ./mozilla curdir=. + /bin/pwd here=/tmp/build/dist/bin + [ 0 != 0 -a -L ./mozilla ] ./mozilla: test: argument expected (set -x uncommented)

even more investigation: If I put the line [ $found != 0 -a -L "$progname" ]; echo $? in the new script right before the "until" statement, I get a 1 on stdout before it hangs, so I'd expect we should never enter the loop at all! Darin: progname gets set to $0 in any case so it's set to "./mozilla" if you run via ./mozilla in command line.

robert: ah, ok.

wait, I've forgotten in previous comment that 1 means error as an exit status and 0 means OK - so it's obvious why the infinite loop happens... AND: I've found the solution - patch will follow in a minute.

current script has until [ $found != 0 -a -L "$progname" ]; that means here: do the loop until the file is found and the caller IS A SYMLINK! we want to do this UNTIL it is NO symlink, right??? My new patch just inserts a NOT for the symlink clause there - and this works with ./mozilla !

attachment 72629 [details] [diff] [review] is working with multiple symlinks, too. I just tested this with the following links: ~/temp/mozilla/heyou -> moz3 moz3 -> moz2 moz2 -> moz1 moz1 -> mozilla mozilla -> /opt/mozilla-build/mozilla (actual mozilla script file) robert@robert:~/temp/mozilla> heyou did really launch mozilla with my patch applied! we'd need r/sr/a here! anyone?

Comment on attachment 72629 [details] [diff] [review] patch for infinite loop problem sr=alecf

ok, I checked in that last patch to get the tree open

Don't we need that fix on the 0.9.9 branch too?

is this the regression at 129075? We need a fix on the branch too.

Attachments 72217 & 72629 have been backed out on the branch. Attachment 72629 [details] [diff] doesn't fix the problem in my tree. Or I should say, it doesn't fix the problem when mozilla is run from dist/bin where it is a symlink. It does fix the problem for the packaged builds (make -C xpinstall/packager). The until test was and is still wrong. We should loop until 'we found run-mozilla.sh' or 'mozilla is not a symlink'. This patch should fix that problem. This new patch also leaves us at the one original fork for the default case. Axel, I changed the until [] to until test but I'm still not sure why solaris' sh would complain about that test and none of the other |if []| tests.

That last patch fixes it for me on Linux.

I have a link /usr/bin/mozilla to /usr/lib/mozilla. The current (1.14) script resolves the link, exits the loop before checking for run-mozilla.sh, and then says: Cannot find mozilla runtime directory. Exiting.

make the loop simpler: loop while link to resolve. break on finding run-mozilla.sh or finding an invalid link.

I meant to say "a link /usr/bin/mozilla to /usr/lib/mozilla/mozilla" ^^^^^^^^

Comment on attachment 73140 [details] [diff] [review] patch r=cls

Comment on attachment 73140 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Patch checked in.

This still doesnt work using the lastest nightly: $ /opt/bin/mozilla /opt/bin/mozilla: /home/davh/../mozilla/run-mozilla.sh: No such file or directory /opt/bin/mozilla: exec: /home/davh/../mozilla/run-mozilla.sh: cannot execute: No such file or directory $ ll /opt/bin/mozilla ~ lrwxrwxrwx 1 root root 18 Aug 28 2001 /opt/bin/mozilla -> ../mozilla/mozilla*

> This still doesnt work using the lastest nightly: > $ /opt/bin/mozilla > /opt/bin/mozilla: /home/davh/../mozilla/run-mozilla.sh: No such file or directory > /opt/bin/mozilla: exec: /home/davh/../mozilla/run-mozilla.sh: cannot execute: No such file or directory > $ ll /opt/bin/mozilla ~ > lrwxrwxrwx 1 root root 18 Aug 28 2001 /opt/bin/mozilla -> ../mozilla/mozilla* If /opt/bin/mozilla is a link to ../mozilla/mozilla, where is /home/davh coming from? What is your MOZILLA_FIVE_HOME set to?

pwd = /home/davh MOZILLA_FIVE_HOME is undefined

It seems that relative links don't work real well. The script changes directory into the currently resolved directory and correctly resolves the relative links from there. But when it's done resolving links, it changes back to the original directory and tries to use the last link, which is no longer valid if it was relative...

fixes ending with a relative link

can you please obsolete the patches that have already landed so this doesn't look like approved changes waiting to land? thanks.

marked the previous symlink patches obselete. AFAIK, they were all checked in.

picard{ah} sh $ if test -h /tmp ; then > echo foo > fi $ if test -L /tmp ; then > echo foo > fi test: argument expected /opt/gnu/bin/test -L /tmp works. Somehow this looks like a bug in solaris' /bin/sh. I tested -h on linux /bin/sh and that works, too. Note that after make install, the starting dir is set to the bin dir, not moz_libdir, but that's a different bug, I suppose. (Not sure if we need to resolve symlinks if we have moz_libdir at all)

*** Bug 149535 has been marked as a duplicate of this bug. ***

*** Bug 149955 has been marked as a duplicate of this bug. ***

*** Bug 150219 has been marked as a duplicate of this bug. ***

*** Bug 59865 has been marked as a duplicate of this bug. ***

*** Bug 148558 has been marked as a duplicate of this bug. ***

*** Bug 151503 has been marked as a duplicate of this bug. ***

Comment on attachment 80934 [details] [diff] [review] patch for mozilla.in on the trunk Use -h instead of -L && r=cls Axel, since the 'make install' step isn't our default install method, we can't just skip straight to always using moz_libdir. Andrew's latest patch appears to make sure that the starting dir should be the cwd not any of the system dirs.

The patch with the s/-L/-h/ change has been checked into the trunk.

*** Bug 151541 has been marked as a duplicate of this bug. ***

Seeing as I can't convince drivers to take various build stopping fixes for the 1.0 branch, I have neither the time nor the patience to attempt to get a symlink fix there. If anyone else feels like evangelizing this annoyance to drivers, feel free. Assuming that the various symlink scenarios are actually fixed by the previous checkin, marking fixed.

Verified fixed with 2002-06-16-04 on Linux. I tried to start mozilla though a relative link and though an absolut link, and both worked.

This is NOT fixed on the aparc-sun-solaris2.7-1.1a 6.14 build in the release 1.1a folder.

This was checked in *after* the 1.1a release. Try a nightly build under /latest-trunk/ or wait for the 1.1b release.

yes, it does work in the solaris 2.6 6/19 build

*** Bug 153132 has been marked as a duplicate of this bug. ***

*** Bug 153768 has been marked as a duplicate of this bug. ***

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

*** Bug 156709 has been marked as a duplicate of this bug. ***

*** Bug 158494 has been marked as a duplicate of this bug. ***