120467 - file names on command lines don't work

Status: RESOLVED WORKSFORME

(Core Graveyard :: Cmd-line Features, enhancement)

Description

[Andreas Kloeckner]

calling "mozilla <some local file name>" from the command line should display
the file instead of trying to resolve host names like "index.html".

Comment 1

[Andrew Schultz]

you and I know that index.html is a local file and that www.mozilla.org is a
website, but Mozilla is going to have a lot more difficulty distinguishing
between them.

perhaps "if DNS fails on apparent hostname, try local file" would work better.

please change severity to "enhancement"

Comment 2

[Andreas Kloeckner]

i think the order should be "try file, then dns". open() is way faster than any
(failing) dns lookup.

Comment 3

[Andrew Schultz]

how about command-line-arguments starting with "." or "/" are local filenames? 
Any filename can be easily represented starting with one of those (./index.html)
and no protocol or hostname can start with them.

The default behavior is still an open issue, but doing the "." and "/" will not
lose any of the current functionality.

Comment 4

[Andrew Schultz]

ok, here's where it gets interesting.  if you already have mozilla running and
try this, it works (it opens a new window in the already-running process with
the file).  with, or without the leading "/", "\" or ".".  If you give it a URL,
it also works.

Comment 5

[Andrew Schultz]

handling arguments beginning with "/" (or "\") as a file seems to be already
implemented.  This helps out a lot because you can use tab completion on the
directories or (if you're in a nasty path) do:

mozilla `pwd`/index.html

Comment 6

[Asa Dotzler [:asa]]

->cmd line component

Comment 7

[Chris Brien]

This should work the same on Windows, too. It does work if you specify the full
path to the file, but in no other situation.

OS => All

Comment 8

[David Illsley]

This seems to be a legitimate RFE at least (if not a bug that it doesn't
currently work) and I can't see a DUPE of it so I am confirming it,

Comment 9

[Andrew Schultz]

comment 4 seems to be specific to RPM and x-remote

Comment 10

[Andrew Schultz]

Attachment: patch to handle ./index.html

if the url starts with "." (./index.html), replace "." with $PWD, making
$PWD/index.html

Comment 11

[Andrew Schultz]

the patch sticks to changing what is obviously a file.  "../" doesn't work
because Mozilla doesn't understand it, so it would need to be handled explicitly.

I think the patch should work on Windows as well, but I can't really test it.

Comment 12

[Andrew Schultz]

Comment on attachment 79391 [details] [diff] [review]
patch to handle ./index.html

strcat does not return a new chunk of memory, so it will step on GetEnv's
memory (freeing it is bad too)!

Comment 13

[Andrew Schultz]

Attachment: patch v2 to handle ./index.html

2nd try.  a bit more complex as it PR_Mallocs its own memory.

Comment 14

[Andrew Schultz]

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

Comment 15

[Pádraig Brady]

Galeon (1.2.7) does as expected (I guess it looks for filename first, then URL).
Links (0.3) does as expected. I know these are unix only but still mozilla
should have the same functionality IMHO.

Comment 16

[Doug Turner (:dougt)]

Comment on attachment 79576 [details] [diff] [review]
patch v2 to handle ./index.html

+    char *pwd = PR_GetEnv("PWD");

I doubt that is portable or even well supported.  You should, if possible, use
the directory service to get the pwd/cwd.

       nsCOMPtr<nsILocalFile>
file(do_CreateInstance("@mozilla.org/file/local;1"));
       if (file)
       {
-	 rv = file->InitWithPath(str);

You probably should just use NS_NewNativeLocalFile()


I think the module owner of this stuff should review this code.

Comment 17

[Vedran Miletic]

retargeting

Comment 18

[Mike Connor [:mconnor]]

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

Comment 19

[Benjamin Smedberg]

We now resolve commandline args relative to the current working directory, which normally works. Firefox also supports -file /path