Closed
Bug 75336
Opened 24 years ago
Closed 23 years ago
Linux: mozilla <file>, <file> shouldn't need "file:" prefix
Categories
(SeaMonkey :: UI Design, defect, P4)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: mcafee, Assigned: law)
Details
(Whiteboard: DUPEME)
Linux.
mozilla "/etc/passwd" renders the homepage (fails)
mozilla "file:/etc/passwd" shows the passwd file, the right thing.
Note that both "/etc/passwd" and "file:/etc/passwd" both work
in the url bar. I think this is broken on the commandline,
this will break all kinds of local scripts, etc. I found this
trying to script tinderbox tests.
-->Networking:File
Assignee: neeti → dougt
Component: Networking → Networking: File
Comment 2•24 years ago
|
||
Invalid.
The parameter is a URL not a file path.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
REOPEN:
This shouldn't work. I'll check again.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 4•23 years ago
|
||
ben, if you reopen a bug, could you give a descriptive reason why.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → INVALID
REOPEN:
I gave a reason. "It shouldn't work."
file:/etc/password is not a valid file URL. If that is valid for some reason,
I'd like to know why.
Once that is clarified, this should probably go to XP apps b/c the real problem
is they should take a path from the line command.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 6•23 years ago
|
||
okay.
Assignee: dougt → pchen
Status: REOPENED → NEW
Component: Networking: File → XP Apps
QA Contact: benc → sairuh
/etc/passwd works in the url bar because it's changed to "file:///etc/passwd",
at any rate, marking p4, minor, and mozilla1.1 because to do this right requires
a bit a of work. First off, what should happen ifI type "mozilla ../index.html"?
It doesn't currently work. I'm hoping adding the ability to support full
pathnames should be easy.
Severity: normal → minor
Priority: -- → P4
Target Milestone: --- → mozilla1.1
Comment 8•23 years ago
|
||
-> default assignee
Assignee: pchen → trudelle
Target Milestone: mozilla1.1 → ---
Comment 10•23 years ago
|
||
This has been fixed for months. I've been using it daily.
I think Benjamin is saying that file:/etc/passwd (as opposed to
file:///etc/passwd) is technically incorrect and shouldn't be supported. First,
that would be a different bug, not this one; second, it had nothing to do with
the fixing of this bug (file:/etc/passwd has worked for at least 6-8 months in
mozilla); and third, that format always worked in NS4 and a lot of people use
it, so if we stop supporting it we'll annoy a lot of people. But in any case,
it has nothing to do with this bug, and I suggest re-closing this one as fixed.
Assignee | ||
Comment 11•23 years ago
|
||
good enough for me
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 12•23 years ago
|
||
Should I file a separate bug then on the fact that Mozilla demands a file:// url whereas normal sane apps will accept a filename?Ÿ
Comment 13•23 years ago
|
||
If you have a reproducible case for that, you should reopen this bug. Nobody
has given one or even mentioned that such a case existed. I run mozilla -edit
/tmp/foo.html and mozilla /home/akkana/foo.html all the time (I also type things
like /tmp/foo.html into the urlbar), so I know those cases work.
Unless you're talking about relative pathnames (e.g. if I'm in my home directory
I can't say "mozilla foo.html" or "mozilla ./foo.html" and have it open a file
in that directory); I think there's already a bug on that (sorry, don't have the
number offhand) but no one has come up with a heuristic that distinguishes that
case from the case "mozilla foo.com".
Reporter | ||
Comment 14•23 years ago
|
||
I agree with Akkana, find a case that doesn't work and reopen if needed.
It looks like mozilla now understands the
mozilla <filename>
format now. I tested with 0.9.6 and it was still broken, but the
trunk build works for me. Verifying.
Status: RESOLVED → VERIFIED
Comment 15•23 years ago
|
||
Yup. I guess I missed it being fixed. :)
I agree that relative pathnames are a different kettle of fish entirely.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•