112080 - /usr/bin/mozilla script inconsistent behavior with filename as command line argument

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[vgb]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112013

The mozilla (/usr/bin/mozilla on Linux) shell script used to start mozilla
behaves differently when a local filename is supplied as the command line
argument, depending on whether or not another mozilla process is currently running.

Reproducible: Always
Steps to Reproduce:
1.Close all mozilla windows
2.Run "mozilla filename" where filename is the name of a local file.
3.Repeat Step 2 with one or more mozilla windows already open.

Actual Results:  With no windows open, the filename is taken as a hostname and
mozilla tries to connect to that host by http. With one or more windows already
open, the argument is taken as a filename, pwd is prepended to it and the file
is opened and displayed.

Expected Results:  It should do the same thing in both cases. Personally I
prefer that both cases open the file but that's just my preference.

Comment 1

[vgb]

Attachment: Modified shell script

This is the script I currently use. It is IMHO somewhat cleaner, and behaves
consistently whether or not there are existing instances.

Comment 2

[timeless]

i presume you're using the redhat package (what url did you get it from?). 
please provide a diff -u.

Comment 3

[vgb]

Attachment: Proposed patch

This is the 0.9.6 release RPM from ftp.mozilla.org - it's the one for RH 6.x.

Here's the patch.

Comment 4

[Akkana Peck]

I made a recent change to command-line argument parsing so that starting mozilla
on a full pathname would work, e.g. "mozilla /tmp/foo.html" turns into "mozilla
file:////tmp/foo.html" (I don't know why it gets four slashes instead of three
-- that's coming from nsILocalFile).  I don't think that change is in 0.9.6. 
But it probably won't work for -remote.  I didn't know the script was doing any
filename rewriting, and I'm not sure exactly what it's supposed to do -- it
doesn't seem to handle relative paths (e.g. "mozilla foo.html" where foo.html is
in the current dir), nor does my arg parsing code (because file urls can't
handle relative paths).

What cases does the script handle, and should we move any of its smarts into the
real arg parsing code (and make sure that -remote goes through the same codepath)?

Maybe none of this is relevant to this bug.  I do agree that it makes sense to
behave consistently whether or not there's a browser window already up.

Comment 5

[vgb]

This is how the script worked before:

If no command line argument, then
      If there is a running instance, then
           open a new window with -remote xfeDoCommand(openBrowser)
      else
           spawn a new instance of mozilla-bin (the mozilla binary)

If first cmdline argument is -mail, then
      If already running instance, then
            pop up a new mail window with -remote xfeDoCommand(openInbox)
      else
            spawn a new mozilla-bin with all the same cmdline arguments, i.e.
"-mail whatever-else-you-have-on-the-cmdline"

if first argument is -compose, then
      If already running instance, then
             pop up a new compose window with xfeDoCommand(composeMessage)
      else
             spawn a new mozilla-bin with all the same arguments

If first argument doesn't start with a -, and if there is an already running
instance, then
       If first argument contains a :/, then
             pass it to -remote openurl()
       else
             If first argument does not start with a /, then
                    If it exists as a relative path, then
                            Convert it to an absolute path
             Pass the (possibly transformed) first argument to -remote openurl()
else
       Spawn a new mozilla-bin with all the same arguments as the script


This is inconsistent all over the place. It always behaves differently depending
on whether there is a running instance or not. For example, if I ran it with
"mozilla -compose [e-mail]", then

If an instance was running, it would just pop up a blank compose window
If no instance was running, it would execute "mozilla-bin -compose [e-mail]"

Similarly with -mail.

I didn't bother with all this. The major change I made is to have the conversion
to absolute paths happen even when there is no existing mozilla-bin instance.

My script still has problems. For example, if you run "mozilla arg1 arg2" where
arg1 is a filename, arg2 is ignored. This is bad. But the previous script would
pass arg2 to mozilla-bin if no previous instance, and ignore it if there was a
previous instance, which was inconsistent.

I'll probably write myself a new script from scratch, as soon as I figure out
what commands -remote takes (http://www.mozilla.org/unix/remote.html is very out
of date, so I'll have to do some poking around the source).

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 7

[Aleksey Nogin]

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

Comment 8

[R.K.Aa.]

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

Comment 9

[Andrew Schultz]

You are correct in saying that

% mozilla filename

works when there are existing processes and not without.  And what you are
saying is that Mozilla should handle "mozilla filename" even when there are no
existing process, is that correct?

I think part of the difficulty is that the RPM script does not have the
sophistication to distinguish between URLs and parameter values.  It only
prepends the path on a filename if it is the *first* argument.

I think I could work that in (prepending the path regardless of existing
processes) as part of bug 122698, but then people will report that (without an
existing process) the following two commandlines work differently:

% mozilla --splash filename
% mozilla filename --splash

ultimately, the script cannot provide absolute consistency (unless this feature
is removed from the startup scripts).  perhaps a more aggressive version of bug
120467 would be a better fix for this.

Comment 10

[vgb]

How about using getopt to help in parsing? On my RH7.3 system, with the default
util-linux (version 2.11n), I have /usr/bin/getopt, which I think can be used to
help with this. Running getopt on the command line sorts the options into a
prescribed order, and puts non-option parameters at the end. (It's just a basic
frontend to the standard GNU getopt library calls.) For example,

$ getopt 'hc:d:' bletch -h -c foo -d bar
 -h -c foo -d bar -- bletch

It also handles long options.

I'm guessing the file or URL if present would be a non-option parameter, so
getopt would help extract it correctly, and this would mean that

mozilla filename --splash

would work the same as

mozilla --splash filename

So here's a suggestion -

- Use getopt to extract options
- If there's a non-option argument it's intended as a URL, so
          - Check if it is an absolute path. If so, pass it as is.
          - If not absolute path, check if prepending $PWD to it gives you an
existing file. If so pass the completed version to mozilla-bin.
          - If both the above failed, just pass everything to mozilla-bin and
let it figure it out.

Problems:

1) I don't know if everyone has the getopt program.

2) I also don't know what to do on Windows. But what do I know (or care) about
Windows.

I'll probably do up a script to implement this tonight and upload it.

Comment 11

[Andrew Schultz]

I was trying to write up a patch for bug 122698 that would also help out here. 
The big problem is handling the non-URL arguments.  The standard script does
moz_run_program ${1+"$@"}  I don't even know what the "1+" does, but the idea is
that it expands to the original commandline arguments.  We need to replace ONE
of those values.  Replacing the first is easy.  Replacing the the end is nasty.
(XP Apps code requires URLs to be the last argument).  can getopt get around
this problem?

getopt is a GNU tool, so will be fairly standard across Linux, but might vary on
other *nix boxes.

Comment 12

[vgb]

It's been a busy week, and I haven't been able to spend too much time on this...

By the way ${1+"$@"} means "if $1 is defined and nonempty then expand to "$@"
otherwise expand to nothing". "$@" is $@ with each element of it quoted; this
protects arguments that may contain spaces and such. I'm assuming this is used
instead of just "$@" because something has trouble handling a "" argument.

I tried using getopt to fix this bug; it's just too painful in a shell script. I
think I'll just redo the whole script in Perl. The existing shell script already
has a couple of perl -e lines, so this should not be a big problem.

The problem with using a shell script is handling things like -compose which
take an optional argument (btw is it just me or does mozilla-bin ignore the
argument supplied with -compose?).

Comment 13

[Andrew Schultz]

mozilla-bin handles "-compose value", but the mozilla script using Xremote does
not.  see bug 149126.  Is that what you're talking about?

Comment 14

[vgb]

No. I'm talking about mozilla-bin itself not doing it, though obviously the
script doesn't handle it either.

Here's my test procedure (mozilla-1.0.0-9 RPMs from mozilla.org):

Test 1:

1) Exit all mozilla windows
2) run "mozilla -compose [e-mail]" (I've also tried mailto:[e-mail])

Test 2:

1) Exit all mozilla windows
2) export the shell variables needed for mozilla (MOZILLA_FIVE_HOME,
LD_LIBRARY_PATH, and anything else exported in the script)
3) Call the binary directly - "/usr/lib/mozilla-1.0.0/mozilla-bin -compose
[e-mail]" (also tried mailto: [e-mail])

Both open up a blank composer window with nothing in the To: field.

The only way I can get it to populate the To: field is to have mozilla open and
use "mozilla-xremote-client 'mailto([e-mail])'".

Comment 15

[Andrew Schultz]

mozilla -help appears to be misleading.  you want:
mozilla -compose to=[e-mail]

Comment 16

[R.K.Aa.]

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

Comment 17

[R.K.Aa.]

from dup bug 161953:

"Expected Results:  Mozilla should remember that
i) it is a file (use file://)
ii) remember the working directory

Pretty sure netscape was fine with this."

(and reporter is right: This is 4xp)

Comment 18

[Tim]

This doesn't appear to belong in build-config.
=> XP Apps / Cmd-line features

Comment 19

[Andrew Schultz]

back to build config.  there is already bug 120467 to handle this in XP Apps.
the purpose of this bug is to consider using the RPM script's handling of files
with relative paths.

it seems pretty hopeless to do it properly (consistently) through the script.
this is because URLs can't be distinguished from other commandline parameters
that happen to be the last argument, and even then, modifying the last argument
in that case is not straightfoward in the script.

recommending WONTFIX.

Comment 20

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 21

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 22

[J. Paul Reed [:preed]]

Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to [e-mail] reflects reality.

If there is a bug you really think we need to be looking at, please *email* [e-mail] with a bug number and explanation.

Comment 23

[Andrew Schultz]

This should work in suiterunner on the trunk (it already works in firefox).  SeaMonkey 1.1 will have the existing instance auto-detect and local file sniffing, but won't handle local files for the case when no existing instance is there, due to issues discussed here.

so, WONTFIX