Closed
Bug 57866
Opened 24 years ago
Closed 23 years ago
allow mozilla to start from symlinks
Categories
(SeaMonkey :: Build Config, defect, P3)
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+
jud
:
approval+
|
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 "$@"
Comment 1•24 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•24 years ago
|
||
Oops, forgot to check 'reassign bug'.
Assignee: asa → don
QA Contact: doronr → sairuh
Comment 3•24 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•24 years ago
|
||
cc cls, granrose says you are the right person
Comment 5•24 years ago
|
||
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
Comment 8•24 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.
Comment 9•24 years ago
|
||
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•24 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.
Comment 11•24 years ago
|
||
it's MOZILLA_HOME now
Updated•24 years ago
|
QA Contact: sairuh → granrose
Comment 12•24 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•24 years ago
|
Target Milestone: --- → mozilla0.6
Reporter | ||
Comment 13•24 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•24 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•24 years ago
|
||
Reporter | ||
Comment 16•24 years ago
|
||
Ok, it's now an attachment.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla1.0
Comment 17•24 years ago
|
||
moving a few 0.9 bugs out to 1.0 to lighten my 0.9 load.
Comment 18•24 years ago
|
||
*** Bug 74304 has been marked as a duplicate of this bug. ***
Comment 19•24 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•24 years ago
|
||
*** Bug 81792 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
I've been bitten by this once too often. Try the patch.
Comment 22•24 years ago
|
||
Comment 23•24 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•24 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•24 years ago
|
||
Comment 26•24 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•24 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•24 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•24 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•24 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•24 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•24 years ago
|
||
OK, how about a perl script? There are far fewer perl versions then shell versions.
Comment 33•24 years ago
|
||
Unfortunately many unix flavors don't have perl with the base operating system.
Comment 34•24 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•24 years ago
|
||
Comment 36•24 years ago
|
||
Comment 37•24 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•24 years ago
|
||
OK, one more shot at this.
Comment 39•24 years ago
|
||
Comment 40•23 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•23 years ago
|
||
Comment 42•23 years ago
|
||
Comment 43•23 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•23 years ago
|
||
Attachment #52773 -
Attachment is obsolete: true
Attachment #53554 -
Attachment is obsolete: true
Assignee | ||
Comment 45•23 years ago
|
||
Taking it back.
Assignee: tenthumbs → seawood
Target Milestone: mozilla1.0.1 → mozilla0.9.9
Assignee | ||
Comment 47•23 years ago
|
||
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
Assignee | ||
Comment 48•23 years ago
|
||
Bah. Forgot to regenerate the patch before attaching it.
Assignee | ||
Updated•23 years ago
|
Attachment #72216 -
Attachment is obsolete: true
Comment 49•23 years ago
|
||
Comment on attachment 72217 [details] [diff] [review] handle symlinks v2.1 Looks good to me.
Attachment #72217 -
Flags: review+
Comment 50•23 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 51•23 years ago
|
||
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.
Assignee | ||
Comment 52•23 years ago
|
||
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.
Assignee | ||
Comment 53•23 years ago
|
||
Atatchment 72217 has been checked into the 0.9.9 branch & the trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
![]() |
||
Comment 54•23 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•23 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•23 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•23 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•23 years ago
|
||
Is this possibly responsible for todays blocker as well (bug 129075)?
Comment 59•23 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•23 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•23 years ago
|
||
robert: ah, ok.
![]() |
||
Comment 62•23 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•23 years ago
|
||
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•23 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•23 years ago
|
||
Comment on attachment 72629 [details] [diff] [review] patch for infinite loop problem sr=alecf
Attachment #72629 -
Flags: superreview+
Comment 66•23 years ago
|
||
ok, I checked in that last patch to get the tree open
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Don't we need that fix on the 0.9.9 branch too?
Comment 68•23 years ago
|
||
is this the regression at 129075? We need a fix on the branch too.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 69•23 years ago
|
||
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.
Assignee | ||
Comment 70•23 years ago
|
||
Comment 71•23 years ago
|
||
That last patch fixes it for me on Linux.
Comment 72•23 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•23 years ago
|
||
make the loop simpler: loop while link to resolve. break on finding run-mozilla.sh or finding an invalid link.
Comment 74•23 years ago
|
||
I meant to say "a link /usr/bin/mozilla to /usr/lib/mozilla/mozilla" ^^^^^^^^
Assignee | ||
Comment 75•23 years ago
|
||
Comment on attachment 73140 [details] [diff] [review] patch r=cls
Attachment #73140 -
Flags: review+
Comment 76•23 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+
Assignee | ||
Comment 77•23 years ago
|
||
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 78•23 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 → ---
Assignee | ||
Comment 79•23 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* 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•23 years ago
|
||
pwd = /home/davh MOZILLA_FIVE_HOME is undefined
Comment 81•23 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•23 years ago
|
||
fixes ending with a relative link
Comment 83•23 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•23 years ago
|
Attachment #73140 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #72700 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #72629 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #72217 -
Attachment is obsolete: true
Comment 84•23 years ago
|
||
marked the previous symlink patches obselete. AFAIK, they were all checked in.
Comment 85•23 years ago
|
||
Comment 86•23 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)
Assignee | ||
Comment 87•23 years ago
|
||
*** Bug 149535 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 88•23 years ago
|
||
*** Bug 149955 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 89•23 years ago
|
||
*** Bug 150219 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Assignee | ||
Comment 90•23 years ago
|
||
*** Bug 59865 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.0.1
Assignee | ||
Comment 91•23 years ago
|
||
*** Bug 148558 has been marked as a duplicate of this bug. ***
Comment 92•23 years ago
|
||
*** Bug 151503 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 93•23 years ago
|
||
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+
Assignee | ||
Comment 94•23 years ago
|
||
The patch with the s/-L/-h/ change has been checked into the trunk.
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 95•23 years ago
|
||
*** Bug 151541 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 96•23 years ago
|
||
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: 23 years ago → 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Comment 97•23 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•23 years ago
|
||
This is NOT fixed on the aparc-sun-solaris2.7-1.1a 6.14 build in the release 1.1a folder.
Assignee | ||
Comment 99•23 years ago
|
||
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•23 years ago
|
||
yes, it does work in the solaris 2.6 6/19 build
Comment 101•23 years ago
|
||
*** Bug 153132 has been marked as a duplicate of this bug. ***
Comment 102•23 years ago
|
||
*** Bug 153768 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Attachment #80934 -
Flags: approval+
Comment 103•23 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+
Assignee | ||
Updated•23 years ago
|
Keywords: mozilla1.0.1+ → fixed1.0.1
Target Milestone: mozilla1.1beta → mozilla1.0.1
Assignee | ||
Comment 104•23 years ago
|
||
*** Bug 156709 has been marked as a duplicate of this bug. ***
Comment 105•23 years ago
|
||
*** Bug 158494 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•