Open Bug 95091 Opened 19 years ago Updated 4 years ago

%s in helper application (or lack of)

Categories

(Firefox :: File Handling, defect)

x86
Linux
defect
Not set
major

Tracking

()

People

(Reporter: Austin_Donnelly, Unassigned)

References

(Blocks 2 open bugs)

Details

Mozilla 0.9.3 (BuildID 2001080104).  Linux ix86.

Once the bugs related to proper mailcap support are resolved, it would be
nice to automatically guess whether the temporary file argument needs to
be appended.  For example a handler of "foo %s" should not have the temp
filename appended, but should have the %s replaced by it.  A handler of
just "foo" should have the temp filename appended to it:

if (substring(helper_app, "%s")) {
    replace(helper_app, "%s", tempfile);
} else {
    strcat(helper_app, tempfile);
}
Depends on: 78919, 83305
Depends on: 52441
Status: UNCONFIRMED → NEW
Ever confirmed: true
->mscott?
Assignee: sgehani → mscott
Summary: RFE: %s in helper application (or lack of) → [RFE] %s in helper application (or lack of)
*** Bug 92142 has been marked as a duplicate of this bug. ***
I think I agree that we need to append the filename if no %s is used.  One
thing, though.  From the mailcap manpage:

  If no "%s" appears in the command field, then instead of placing the message
  body in a temporary file, metamail will pass the body to the command on the
  standard input. This is helpful in saving /tmp file space, but can be
  problematic for window-oriented applications under some window systems such
  as MGR.

I feel that the justification for sticking to spec on this one is slim,
especially since we don't have a good way to pass in the contents to the app on
stdin with the current helper architecture in Mozilla.  But I thought I'd throw
this out there...
Component: Preferences → File Handling
If this is done, please check for more than the occurance of %s before you add
%s to the end of the command.

For instance: I usually have the URL of MP3's appended to the playlist of XMMS
when I click on them.
The mailcap line looks like this:
audio/mpeg;xmms -e '%u'

This is a case where %s doesn't work too good since the "xmms -e" command exits
immediately after adding the file to the playlist if xmms is already running.

By the way...the mailcap standard (not the manpage but
http://www.ietf.org/rfc/rfc1524.txt) says nothing for or against adding %s
Blocks: 115041
So... what is the expected behavior for %u (which is not mentioned anywhere in
the mailcap standard or mailcap documentation)?

I've seen it used in the RealPlayer mailcap lines, and I'm not quite sure what
to do with it, to be truthful...  Would it make sense to just treat %u as
equivalent to %s?
I'm guessing %u is the URL clicked on?
This isn't an RFE this is a 4.x parity bug and is a major limitation with helper
apps.
Severity: enhancement → normal
Keywords: 4xp, mozilla1.0
Summary: [RFE] %s in helper application (or lack of) → %s in helper application (or lack of)
A friend from Pitzer just asked me why he couldn't get helper apps for pdf and
ps to work in Mozilla on SunOS.  He used 'acroread %s' and 'ggv %s' as helper
app entries because that's how Netscape 4 had them.  Both acroread and ggv would
exit immediately with those settings.  I was only able to help him solve the
problem because I was used to not seeing %s in the "what do you want to do with
this file?" dialog on Windows.
Severity: normal → major
Jesse, is your friend editing his Mozilla settings or his Netscape settings? 
The Mozilla settings are unlikely to support %s until bug 78919 (complete
redesign of the helper app stuff) is fixed.  %s support in actual mailcap
entries will happen much sooner than that....
*** Bug 142534 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
Assignee: mscott → nobody
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.