187055 - total blocker for non-programmers: run-mozilla.sh shellscript wrongly exits because of poor shell variable assignments

Status: VERIFIED INVALID

(SeaMonkey :: Build Config, defect)

Description

[Aaron R. Kulkis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

Anonymous script writer apparently tested run-mozilla from the installation
directory...and didn't realize that it doesn't work from any place else. (SHAME
SHAME!!!)

Reproducible: Always

Steps to Reproduce:
1. Install on Linux (intel or AMD system)
2. Attempt to run by using the shellscript run-mozilla
3. run-mozilla will exit because it can't find the binary.

Actual Results:  
akulkis@pcp02859628pcs:~> /opt/mozilla1.3a/run-mozilla.sh

run-mozilla.sh: Cannot execute .

akulkis@pcp02859628pcs:~> bash -x /opt/mozilla1.3a/run-mozilla.sh
++ basename /opt/mozilla1.3a/run-mozilla.sh
+ cmdname=run-mozilla.sh
++ dirname /opt/mozilla1.3a/run-mozilla.sh
+ MOZ_DIST_BIN=/opt/mozilla1.3a
+ MOZ_DEFAULT_NAME=./run-mozilla.sh-bin
+ MOZ_APPRUNNER_NAME=./mozilla-bin
+ MOZ_VIEWER_NAME=./viewer
+ MOZ_PROGRAM=
+ exitcode=0
+ moz_debug=0
+ moz_debugger=
+ '[' 0 -gt 0 ']'
+ '[' 0 -gt 0 ']'
+ '[' -z '' ']'
+ '[' -x ./run-mozilla.sh-bin ']'
+ '[' -x ./viewer ']'
+ '[' -x ./mozilla-bin ']'
+ '[' '!' -x '' ']'
+ moz_bail 'Cannot execute .'
+ message=Cannot execute .
+ echo

+ echo 'run-mozilla.sh: Cannot execute .'
run-mozilla.sh: Cannot execute .
+ echo

+ exit 1
akulkis@pcp02859628pcs:~>


Expected Results:  
Found and run the freakin' binary ;-)

easy fix....bad shell-variable assignments on lines 68-71 of the script:

     66 cmdname=`basename "$0"`
     67 MOZ_DIST_BIN=`dirname "$0"`
     68 MOZ_DEFAULT_NAME="./${cmdname}-bin"
     69 MOZ_APPRUNNER_NAME="./mozilla-bin"
     70 MOZ_VIEWER_NAME="./viewer"
     71 MOZ_PROGRAM=""

should be

     66 cmdname=`basename "$0"`
     67 MOZ_DIST_BIN=`dirname "$0"`
     68 MOZ_DEFAULT_NAME="${MOZ_DIST_BIN}/${cmdname}-bin"
     69 MOZ_APPRUNNER_NAME="${MOZ_DIST_BIN}/mozilla-bin"
     70 MOZ_VIEWER_NAME="${MOZ_DIST_BIN}/viewer"
     71 MOZ_PROGRAM=""

Then, put a one line shell-script somewhere in a universally recognized
execution path, such as /usr/X11R6/bin

#!/bin/sh
MOZILLADIR=/opt/mozilla1.3a      # this should be set up by the install script

$MOZILLA_DIR/run-mozilla.sh
exit 0

Comment 1

[Matthias Versen [:Matti]]

doesn't block development

Comment 2

[Kenneth Herron]

Per the release notes, mozilla should normally be launched using the "mozilla"
script. run-mozilla.sh is just for developers running mozilla from the build
directory. It even contains a comment to this effect:

## This script is meant to run a mozilla program from the mozilla
## source tree.  This is mostly useful to folks hacking on mozilla.

Comment 3

[hacker formerly known as [e-mail]]

v.

Comment 4

[Aaron R. Kulkis]

[e-mail] right about run-mozilla.sh.  (I was up late
when I found this and worked out my own work-around).

However, Something is still wrong with the 1.3a install process.

I guess my original report wasn't as accurate as it should have
been, because I was dealing with code I had never looked at
before.  The ONLY reason which I started digging into the script
is because when I upgraded from 1.01 (as installed on SuSE 8.1)
to 1.3a, the commmand "mozilla" stopped working.  (I moved the
old mozilla from /opt/mozilla to /opt/mozilla1.01, and then
used ln -s to point /opt/mozilla at /opt/mozilla1.3a).


So, following the output of "which mozilla", I discovered the
1.01 shell script (mozilla) in /usr/X11R6/bin...and followed
things from there.

Anyways, the point is, the typical user (a NON-programmer)
is going to be quite annoyed if they download 1.3a, and
the command "mozilla" no longer works, their desktop icon
to start it doesn't work, and most of all, since they aren't
programmers, don't even know where to begin to fix it.

I understand this is only the alpha-level release...but,
because it's like having a $150,000 Lambourghini with a
defective starter switch, a bad wrapper script is a total
show-stopper for the non-technical users out there, and it
reflects poorly on everybody's otherwise excellant work.

Although I know C, I haven't used it in 13 years, and I still
haven't learned C++ or Java, so I wouldn't call myself a
programmer any more--I earn my keep as a sysadmin.

And the one thing I know is this: USERS expect that when
a program is upgraded, it should start up with the exact
same command line they used to use before...otherwise, they
become quite annoyed and dispondant.

Whoever is in charge of the installation process should be
taking care to make SURE that a normal PATH variable set
for GUI use (i.e. one that does NOT explicitly include
the netscape installation directory, but DOES include
/usr/X11R6/bin) has a WORKING wrapper script called "netscape",
which, when executed, fires up the 1.3a code.

Anything less, and a LOT of non-technical users are going to
be lost, and lot of corporate sysadmins annoyed that a 5 minute
process has turned into an half hour debugging session.

If we want the managers out there (and yes, there are a lot
of non-technical people in IT management) to trust Open Source
solutions, then we MUST achieve the same level of accomplishment.

One person fixing the install script * 2 hours = 2 man hours.

2,000 sysadmins * .5 hours fixing the install = 1,000 man hours.


I know I've started rambling here but...there was no need to change
this aspect of install procedure in the first place.  The installation
code for 1.01 works...why screw with it?



and wrapper script changed in the first place?

Comment 5

[hacker formerly known as [e-mail]]

If you can download the tarball, untar it into a directory and run ./mozilla
from within that directory (or even a symlink from another directory to that
script), then our job here is done.  The extra stuff like a symlink to your
desktop is generally handled by people who put together the OS distribution.

While rambling and needlessly lecturing, you neglected to mention a few things:
1) where did the original 1.01 installation come from?
2) did you upgrade using the tarball, rpms, debs or 'make install'?

Also, note that the rpms/debs are contributed builds which means that we have no
direct control over how they are packaged or what they do.  If you have a
problem that's specific to those packages, you should take it up with their
maintainers, which should be listed in their packages.

Comment 6

[Tracy Walker [:tracy]]

verified