Closed Bug 57866 Opened 24 years ago Closed 22 years ago

allow mozilla to start from symlinks

Categories

(SeaMonkey :: Build Config, defect, P3)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: chowes, Assigned: netscape)

References

Details

Attachments

(3 files, 14 obsolete files)

13.80 KB, text/plain
Details
533 bytes, patch
Details | Diff | Splinter Review
1.12 KB, patch
netscape
: review+
Details | Diff | Splinter Review
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.
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: Cmd-line Features
Ever confirmed: true
Oops, forgot to check 'reassign bug'.
Assignee: asa → don
QA Contact: doronr → sairuh
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
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
Assignee: don → alecf
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
QA Contact: sairuh → granrose
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?
Target Milestone: --- → mozilla0.6
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.
Target Milestone: mozilla0.6 → mozilla0.9
Ok, it's now an attachment.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla1.0
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.
Attached patch yet another "mozilla" patch (obsolete) — Splinter Review
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
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.
Attached patch updated patch (obsolete) — Splinter Review
Attached file perl script (obsolete) —
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.
Attached file mozlaunch.c (obsolete) —
Attached file better mozlaunch.c (obsolete) —
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
Attached file new code (obsolete) —
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
Attached file mozlaunch.c
An even better version.
Attachment #60076 - Attachment is obsolete: true
Attached patch handle symlinks v2.0 (obsolete) — Splinter Review
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
Attached patch handle symlinks v2.1 (obsolete) — Splinter Review
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 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
Closed: 22 years ago
Resolution: --- → FIXED
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)"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.

Attached patch patch for infinite loop problem (obsolete) — Splinter Review
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
Attachment #72629 - Flags: superreview+
ok, I checked in that last patch to get the tree open
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
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.

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: patchmozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Attached patch loop fix v2.0 (obsolete) — Splinter Review
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.
Attached patch patch (obsolete) — Splinter Review
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

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73140 - Flags: approval+
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
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*
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?

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...
Attached patch one more patchSplinter Review
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.
Attachment #73140 - Attachment is obsolete: true
Attachment #72700 - Attachment is obsolete: true
Attachment #72629 - Attachment is obsolete: true
Attachment #72217 - Attachment is obsolete: true
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. ***
Target Milestone: mozilla1.0 → mozilla1.0.1
*** 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.
Attachment #80934 - Flags: review+
The patch with the s/-L/-h/ change has been checked into the trunk.
Status: REOPENED → ASSIGNED
Keywords: patch, reviewmozilla1.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
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.1 → mozilla1.1beta
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
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. ***
Attachment #80934 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Target Milestone: mozilla1.1beta → mozilla1.0.1
*** Bug 156709 has been marked as a duplicate of this bug. ***
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: