allow mozilla to start from symlinks

VERIFIED FIXED in mozilla1.0.1

Status

SeaMonkey
Build Config
P3
minor
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: chowes, Assigned: hacker formerly known as seawood@netscape.com)

Tracking

Trunk
mozilla1.0.1
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 14 obsolete attachments)

13.80 KB, text/plain
Details
533 bytes, patch
Details | Diff | Splinter Review
1.12 KB, patch
hacker formerly known as seawood@netscape.com
: review+
Judson Valeski
: approval+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
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 "$@"

Comment 1

17 years ago
Changing component over to XP Apps: Cmd-line Features.

Changes look like they should work alright (untested), marking New.
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: Cmd-line Features
Ever confirmed: true

Comment 2

17 years ago
Oops, forgot to check 'reassign bug'.
Assignee: asa → don
QA Contact: doronr → sairuh

Comment 3

17 years ago
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.
Component: XP Apps: Cmd-line Features → Build Config
Keywords: patch

Comment 4

17 years ago
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
(Reporter)

Comment 6

17 years ago
--- 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
Assignee: don → alecf

Comment 8

17 years ago
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
(Reporter)

Comment 10

17 years ago
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
QA Contact: sairuh → granrose

Comment 12

17 years ago
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?

Updated

17 years ago
Target Milestone: --- → mozilla0.6
(Reporter)

Comment 13

17 years ago
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

Comment 14

17 years ago
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.
Target Milestone: mozilla0.6 → mozilla0.9
(Reporter)

Comment 15

17 years ago
Created attachment 19225 [details] [diff] [review]
New patch for 'mozilla' shell script
(Reporter)

Comment 16

17 years ago
Ok, it's now an attachment.

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla1.0

Comment 17

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

Comment 18

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

Comment 19

17 years ago
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.

Comment 20

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

Comment 21

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

Comment 22

17 years ago
Created attachment 35483 [details] [diff] [review]
yet another "mozilla" patch

Comment 23

17 years ago
I dunno, this looks ok to me.. sr=alecf if cls or another unix guru (mcafee?)
will review
Assignee: alecf → tenthumbs
Status: ASSIGNED → NEW
Summary: enhancement to mozilla startup shell script → allow mozilla shell script to run from symlinks

Comment 24

17 years ago
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.

Comment 25

17 years ago
Created attachment 35816 [details] [diff] [review]
patch that also honors MOZILLA_FIVE_HOME

Comment 26

17 years ago
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.

Comment 27

17 years ago
+# 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.

Comment 28

17 years ago
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.

Comment 29

17 years ago
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?

Comment 30

17 years ago
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.

Comment 31

17 years ago
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

Comment 32

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

Comment 33

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

Comment 34

17 years ago
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.

Comment 35

17 years ago
Created attachment 36135 [details] [diff] [review]
updated patch

Comment 36

17 years ago
Created attachment 36136 [details]
perl script

Comment 37

17 years ago
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.

Comment 38

17 years ago
OK, one more shot at this.

Comment 39

17 years ago
Created attachment 44016 [details] [diff] [review]
another try, this one doesn't try for completely absolute pathnames

Comment 40

16 years ago
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.

Comment 41

16 years ago
Created attachment 52773 [details]
mozlaunch.c

Comment 42

16 years ago
Created attachment 53554 [details]
better mozlaunch.c

Comment 43

16 years ago
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.
Summary: allow mozilla shell script to run from symlinks → allow mozilla to start from symlinks
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 44

16 years ago
Created attachment 60076 [details]
new code
Attachment #52773 - Attachment is obsolete: true
Attachment #53554 - Attachment is obsolete: true
Taking it back.
Assignee: tenthumbs → seawood
Target Milestone: mozilla1.0.1 → mozilla0.9.9

Comment 46

16 years ago
Created attachment 65285 [details]
mozlaunch.c

An even better version.
Attachment #60076 - Attachment is obsolete: true
Created attachment 72216 [details] [diff] [review]
handle symlinks v2.0

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.
Attachment #19225 - Attachment is obsolete: true
Attachment #35483 - Attachment is obsolete: true
Attachment #35816 - Attachment is obsolete: true
Attachment #36135 - Attachment is obsolete: true
Attachment #36136 - Attachment is obsolete: true
Attachment #44016 - Attachment is obsolete: true
Created attachment 72217 [details] [diff] [review]
handle symlinks v2.1

Bah.  Forgot to regenerate the patch before attaching it.
Attachment #72216 - Attachment is obsolete: true
Comment on attachment 72217 [details] [diff] [review]
handle symlinks v2.1

Looks good to me.
Attachment #72217 - Flags: review+

Comment 50

16 years ago
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
Attachment #72217 - Flags: approval+
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 54

16 years ago
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...

Comment 55

16 years ago
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)"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 56

16 years ago
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.

Comment 57

16 years ago
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??

Comment 58

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

Comment 59

16 years ago
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)

Comment 60

16 years ago
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.

Comment 61

16 years ago
robert: ah, ok.

Comment 62

16 years ago
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.

Comment 63

16 years ago
Created attachment 72629 [details] [diff] [review]
patch for infinite loop problem

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 !

Comment 64

16 years ago
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 65

16 years ago
Comment on attachment 72629 [details] [diff] [review]
patch for infinite loop problem

sr=alecf
Attachment #72629 - Flags: superreview+

Comment 66

16 years ago
ok, I checked in that last patch to get the tree open
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Don't we need that fix on the 0.9.9 branch too?

Comment 68

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → ASSIGNED
Keywords: patch → mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Created attachment 72700 [details] [diff] [review]
loop fix v2.0

Comment 71

16 years ago
That last patch fixes it for me on Linux.

Comment 72

16 years ago
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.

Comment 73

16 years ago
Created attachment 73140 [details] [diff] [review]
patch

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

Comment 74

16 years ago
I meant to say "a link /usr/bin/mozilla to /usr/lib/mozilla/mozilla"
                                                   ^^^^^^^^
Comment on attachment 73140 [details] [diff] [review]
patch

r=cls
Attachment #73140 - Flags: review+

Comment 76

16 years ago
Comment on attachment 73140 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73140 - Flags: approval+
Patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 78

16 years ago
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*
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 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?

Comment 80

16 years ago
pwd = /home/davh
MOZILLA_FIVE_HOME is undefined

Comment 81

16 years ago
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...

Comment 82

16 years ago
Created attachment 76371 [details] [diff] [review]
one more patch

fixes ending with a relative link

Comment 83

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

Updated

16 years ago
Attachment #73140 - Attachment is obsolete: true

Updated

16 years ago
Attachment #72700 - Attachment is obsolete: true

Updated

16 years ago
Attachment #72629 - Attachment is obsolete: true

Updated

16 years ago
Attachment #72217 - Attachment is obsolete: true

Comment 84

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

Comment 85

16 years ago
Created attachment 80934 [details] [diff] [review]
patch for mozilla.in on the trunk

Comment 86

16 years ago
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. ***

Updated

16 years ago
Keywords: mozilla1.0 → mozilla1.1, patch, review
*** Bug 59865 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 148558 has been marked as a duplicate of this bug. ***

Comment 92

16 years ago
*** 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.
Attachment #80934 - Flags: review+
The patch with the s/-L/-h/ change has been checked into the trunk.
Status: REOPENED → ASSIGNED
Keywords: patch, review → mozilla1.0.1
*** 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.1 → mozilla1.1beta

Comment 97

16 years ago
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.
Status: RESOLVED → VERIFIED

Comment 98

16 years ago
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.

Comment 100

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

Comment 101

16 years ago
*** Bug 153132 has been marked as a duplicate of this bug. ***
*** Bug 153768 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Attachment #80934 - Flags: approval+

Comment 103

16 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Keywords: mozilla1.0.1+ → fixed1.0.1
Target Milestone: mozilla1.1beta → mozilla1.0.1
*** Bug 156709 has been marked as a duplicate of this bug. ***

Comment 105

16 years ago
*** Bug 158494 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.