Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Karl Kleinpaste]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Quite a long time back, I recall there being some hackery done in
Gnus, or perhaps W3, regarding proper inlining of <img src=cid:...>
images within a text/html message.  As I see things today, in
CVS-current 5.8.4, the inlining doesn't happen at all, and instead the
cid:foo identifier is displayed in [square brackets] as the "content"
of the text/html message.  Oddly, even the content ID string dispalyed
is mangled, being cut off at the first `.' -- is that perhaps the bug?

Or is there some knob I'm supposed to have twisted in order to get the
image to inline with the text/html directly?

If you `C-d', you can see all the component parts, of course, but I
wouldn't think I'd have to work that hard -- it's already supposed to
show the image in question.

Test message follows, using a smallish .gif image.  "M-x w3-version
RET" reveals "4.0pre.46", which is current in xemacs-packages.

--karl

"Gnus, or: How I Learned To Stop Worrying And Love HTML"


[-- Attachment #2: Type: message/rfc822, Size: 10647 bytes --]

[-- Attachment #2.1.1: Type: text/html, Size: 51 bytes --]

[-- Attachment #2.1.2: world.gif --]
[-- Type: image/gif, Size: 7434 bytes --]

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[William M. Perry]

Karl Kleinpaste <karl@justresearch.com> writes:

> Quite a long time back, I recall there being some hackery done in Gnus,
> or perhaps W3, regarding proper inlining of images within a text/html
> message. As I see things today, in CVS-current 5.8.4, the inlining
> doesn't happen at all, and instead the cid:foo identifier is displayed in
> [square brackets] as the "content" of the text/html message. Oddly, even
> the content ID string dispalyed is mangled, being cut off at the first
> `.' -- is that perhaps the bug? Or is there some knob I'm supposed to
> have twisted in order to get the image to inline with the text/html
> directly? If you `C-d', you can see all the component parts, of course,
> but I wouldn't think I'd have to work that hard -- it's already supposed
> to show the image in question. Test message follows, using a smallish
> .gif image. "M-x w3-version RET" reveals "4.0pre.46", which is current in
> xemacs-packages.

Hrmm... Is the content-id supposed to have <...> around it?  Emacs/W3 just
looks for it raw.  Look at your messages buffer - do you see something like
"Unknown CID encountered: ..."?

-Bill P.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Karl Kleinpaste]

wmperry@aventail.com (William M. Perry) writes:
> Hrmm... Is the content-id supposed to have <...> around it?  Emacs/W3 just
> looks for it raw.  Look at your messages buffer - do you see something like
> "Unknown CID encountered: ..."?

Just tried it again, with the same example message.  No "unknown CID"
message.  *Message-Log* contains only...
        Parsed 100% of 52...done
        Drawing... \
...and nothing more.  Editing the angle brackets out of the Content-ID
header doesn't change the behavior at all.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@justresearch.com> writes:

> Quite a long time back, I recall there being some hackery done in
> Gnus, or perhaps W3, regarding proper inlining of <img src=cid:...>
> images within a text/html message.  As I see things today, in
> CVS-current 5.8.4, the inlining doesn't happen at all, and instead the
> cid:foo identifier is displayed in [square brackets] as the "content"
> of the text/html message. 

I think I saw this once, but hitting `g' on the article once or twice
made things all pretty and stuff.  I haven't looked at that for a
while, though -- does this do the trick for you as well?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Michael Harnois]

On 20 Apr 2000 22:26:38 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

    > I think I saw this once, but hitting `g' on the article once or
    > twice made things all pretty and stuff. I haven't looked at that
    > for a while, though -- does this do the trick for you as well?

I just recently started getting some daily cartoons (Doonesbury and
Bizarro) through memail and ran into this problem. If I hit `g' enough
times I can get some of the other art on the page to render, but I
can't get the cartoon. And if I click on the link to the cartoon, I
get a popup dialog asking me if I want to fetch the link; if I click
Yes the dialog box disappears, but the message in the minibuffer
continues to say "please answer the dialog box" and the process hangs.

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mdharnois@home.com                      aa0bt@aa0bt.ampr.org 
 There are things that are so serious 
 that you can only joke about them. -- Werner Heisenberg

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

Michael Harnois <mdharnois@home.com> writes:

> I just recently started getting some daily cartoons (Doonesbury and
> Bizarro) through memail and ran into this problem. If I hit `g' enough
> times I can get some of the other art on the page to render, but I
> can't get the cartoon. And if I click on the link to the cartoon, I
> get a popup dialog asking me if I want to fetch the link; if I click
> Yes the dialog box disappears, but the message in the minibuffer
> continues to say "please answer the dialog box" and the process hangs.

Can you forward me such a message?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Michael Harnois]

This has gotten much better now. When I C-g after things are hung,
XEmacs just segfaults.

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mdharnois@home.com                      aa0bt@aa0bt.ampr.org 
 Never, "for the sake of peace and quiet," deny 
 your own experience or convictions. -- Dag Hammarskjold

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

Michael Harnois <mdharnois@home.com> writes:

> This has gotten much better now. When I C-g after things are hung,
> XEmacs just segfaults.

That's progress.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Michael Harnois]

On 22 Apr 2000 14:14:02 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

    > That's progress. :-)

I have more progress now, having found out 1) there's a dialog box bug in
the current XEmacs CVS and 2) gnus expects electric eyes to be ee,
while it is eeyes on my system. Having worked out those two things, I
find when I retrieve the image, gnus says it's writing a temp file
that will be passed to ee, but the temp file does not seem to get created.

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mdharnois@home.com                      aa0bt@aa0bt.ampr.org 
 The opposite of a correct statement is a false statement.
 The opposite of a profound truth may well be another profound truth.
  -- Niels Bohr

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

Michael Harnois <mdharnois@home.com> writes:

> I have more progress now, having found out 1) there's a dialog box bug in
> the current XEmacs CVS and 2) gnus expects electric eyes to be ee,
> while it is eeyes on my system. Having worked out those two things, I
> find when I retrieve the image, gnus says it's writing a temp file
> that will be passed to ee, but the temp file does not seem to get created.

When I view stuff externally (with xv), the temp file does get created
OK for me...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Roland Mas]

Lars Magne Ingebrigtsen (2000-08-10 20:48:02 +0200) :

> Michael Harnois <mdharnois@home.com> writes:
> 
> > I have more progress now, having found out 1) there's a dialog box bug in
> > the current XEmacs CVS and 2) gnus expects electric eyes to be ee,
> > while it is eeyes on my system. Having worked out those two things, I
> > find when I retrieve the image, gnus says it's writing a temp file
> > that will be passed to ee, but the temp file does not seem to get created.
> 
> When I view stuff externally (with xv), the temp file does get created
> OK for me...

Could depend on the file name.  There are some problems with filenames
with spaces in them, which I personnally have to view with the 'Pipe
to command' display method.

Roland.
-- 
Roland Mas

It would be hard to be deader without special training.
  -- in Theatre of Cruelty (Terry Pratchett)

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

Roland Mas <mas@echo.fr> writes:

> Could depend on the file name.  There are some problems with filenames
> with spaces in them, which I personnally have to view with the 'Pipe
> to command' display method.

Huh.  Let's see:


[-- Attachment #2: r m s .jpg --]
[-- Type: image/jpeg, Size: 889 bytes --]

[-- Attachment #3: Type: text/plain, Size: 104 bytes --]


-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Huh.  Let's see:

Worked for me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Rene H. Larsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Roland Mas <mas@echo.fr> writes:
> 
> > Could depend on the file name.  There are some problems with filenames
> > with spaces in them, which I personnally have to view with the 'Pipe
> > to command' display method.
> 
> Huh.  Let's see:

On my system xv gives this error message:

  Can't open file '/tmp/renehl/emm.mZAnEu/r\ m\ s\ .jpg'

when I choose "View Externally" from the right-click menu.

Platform: XEmacs 21.1.12 / CVS Gnus as of 1½ hours ago
-- 
Echelon bait:
Lon Horiuchi FSF militia genetic nuclear SCUD missile radar Panama
strategic Clinton NWO smuggle encryption [Hello to all my fans in
domestic surveillance] class struggle

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[ShengHuo ZHU]

"Rene H. Larsen" <rhl@traceroute.dk> writes:

> On my system xv gives this error message:
> 
>   Can't open file '/tmp/renehl/emm.mZAnEu/r\ m\ s\ .jpg'
> 
> when I choose "View Externally" from the right-click menu.

Check your mailcap files.  The image/jpeg entry should look like

    image/jpeg; xv %s

instead of

    image/jpeg; xv '%s'

or

    image/jpeg; xv "%s"

ShengHuo

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Kai Großjohann]

On 11 Aug 2000, ShengHuo ZHU wrote:

> Check your mailcap files.  The image/jpeg entry should look like
> 
>     image/jpeg; xv %s
> 
> instead of
> 
>     image/jpeg; xv '%s'

My Debian potato installation contains /etc/mailcap with:

    image/jpeg; xv '%s'

My home dir contains ~/.mailcap with:

    image/*; xv %s

The value of mailcap-mime-data contains the ~/.mailcap entry first,
and the /etc/mailcap entry after that.

When viewing a JPEG file, Gnus uses the /etc/mailcap entry.

Hm.

How are /etc/mailcap and ~/.mailcap supposed to interact?  OT1H,
~/.mailcap should override /etc/mailcap, but OTOH, more specific
settings should override more general settings.

But somehow, this feels wrong.  After all, I told it to use xv for all
kinds of images in my ~/.mailrc -- why should I have to specify each
image type separately?

Or maybe Gnus does use the first matching entry it finds, but searches
from the end of the list, rather than from the beginning?

kai
-- 
I like BOTH kinds of music.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[ShengHuo ZHU]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

[...]

> My Debian potato installation contains /etc/mailcap with:
> 
>     image/jpeg; xv '%s'

The entry of /etc/mailcap of Redhat (6.2?) is

    image/*; ee %s

Though RFC 1343 did not explicitly say anything about the quoted %s,
the examples use naked %s.  I think naked %s should be good enough.

> Or maybe Gnus does use the first matching entry it finds, but
> searches from the end of the list, rather than from the beginning?

mailcap-mime-data is stored in the last-entry-first order.
        
ShengHuo

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Kai Großjohann]

On 11 Aug 2000, ShengHuo ZHU wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> Or maybe Gnus does use the first matching entry it finds, but
>> searches from the end of the list, rather than from the beginning?
> 
> mailcap-mime-data is stored in the last-entry-first order.

Oh.  Does that mean that /etc/mailcap entries will always override
~/.mailcap entries?  IMVHO, it should be vice-versa.

kai
-- 
I like BOTH kinds of music.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[ShengHuo ZHU]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 11 Aug 2000, ShengHuo ZHU wrote:
> 
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > 
> >> Or maybe Gnus does use the first matching entry it finds, but
> >> searches from the end of the list, rather than from the beginning?
> > 
> > mailcap-mime-data is stored in the last-entry-first order.

> Oh.  Does that mean that /etc/mailcap entries will always override
> ~/.mailcap entries?  IMVHO, it should be vice-versa.

Oops. I was wrong. It should be last-parsed-file-first. The parsing
order is "/usr/local/etc/mailcap" "/usr/etc/mailcap" "/etc/mailcap"
"~/.mailcap", i.e. ~/.mailcap entries override /etc/mailcap ones.  But
the best viewer is selected according to mailcap-viewer-lessp.

ShengHuo

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Kai Großjohann]

On 11 Aug 2000, ShengHuo ZHU wrote:

> Oops. I was wrong. It should be last-parsed-file-first. The parsing
> order is "/usr/local/etc/mailcap" "/usr/etc/mailcap" "/etc/mailcap"
> "~/.mailcap", i.e. ~/.mailcap entries override /etc/mailcap ones.
> But the best viewer is selected according to mailcap-viewer-lessp.

So this means that Gnus will prefer the image/gif entry over an
image/* entry, regardless which file each came from?  I haven't
grokked the source, only scanned it.  But that's the way it looks.

Hm.

IMHO, an image/* entry in ~/.mailcap should override an image/gif
entry from /etc/mailcap.

Is there a standard of some kind that we can turn to to find out what
is the right behavior?  Should the behavior of the metamail program be
considered a standard?

kai
-- 
I like BOTH kinds of music.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Daniel Pittman]

On 13 Aug 2000, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
wrote:

> On 11 Aug 2000, ShengHuo ZHU wrote:

[...]

> Is there a standard of some kind that we can turn to to find out what
> is the right behavior?  Should the behavior of the metamail program be
> considered a standard?

Last time I went hunting for information on this, that was the closest I
got. 'metamail' seems to be the /only/ reference to how it 'should'
work, and that's not actually documented.

Which is less than ideal, I think.

        Daniel

-- 
> What should I look for in a good bird bath?
And in response, thus spake the Oracle:
} In a good bird bath? I'd expect to find birds.
} In a bad bird bath, tarantulas.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[William M. Perry]

"Daniel Pittman" <daniel@danann.net> writes:

> On 13 Aug 2000, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
> wrote:
> 
> > On 11 Aug 2000, ShengHuo ZHU wrote:
> 
> [...]
> 
> > Is there a standard of some kind that we can turn to to find out what
> > is the right behavior?  Should the behavior of the metamail program be
> > considered a standard?
> 
> Last time I went hunting for information on this, that was the closest I
> got. 'metamail' seems to be the /only/ reference to how it 'should'
> work, and that's not actually documented.

RFC 1343 is where you should look - there are relevant chunks quoted from
it in the emacs/w3 manual.  It doesn't really seem to have anything to say
on dealing with multiple mailcap files.

We could assign a new weight by file location, and use that in
mm-viewer-lessp, but that could get tricky.

-Bill P.

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Rene H. Larsen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> "Rene H. Larsen" <rhl@traceroute.dk> writes:
> 
> > On my system xv gives this error message:
> > 
> >   Can't open file '/tmp/renehl/emm.mZAnEu/r\ m\ s\ .jpg'
> > 
> > when I choose "View Externally" from the right-click menu.
> 
> Check your mailcap files.  The image/jpeg entry should look like
> 
>     image/jpeg; xv %s
> 
> instead of
> 
>     image/jpeg; xv '%s'

Hmm, that's pretty bad, since all the mailcap entries shipped with
Debian GNU/Linux use the quoted form. All of the Debian MIME-handling
utilities expect the entries to be quoted as well.

It would be nice if there was an option to flip in Gnus so that it
won't escape spaces in filenames passed to mailcap handlers. This
would make it compatible with the way Debian (and others?) handles
mailcap quoting.

What do you think?
-- 
Echelon bait:
SEAL Team 6 SCUD missile Monica Lewinsky cryptographic Mossad quiche
constitution White Water spy Ron Brown Semtex Treasury cypherpunk
Panama class struggle

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[Rene H. Larsen]

"Rene H. Larsen" <rhl@traceroute.dk> writes:

> Hmm, that's pretty bad, since all the mailcap entries shipped with
> Debian GNU/Linux use the quoted form. All of the Debian
> MIME-handling utilities expect the entries to be quoted as well.

In fact, they are all single-quoted.  I suppose that is Debian policy
on mailcap entries.

> It would be nice if there was an option to flip in Gnus so that it
> won't escape spaces in filenames passed to mailcap handlers. This
> would make it compatible with the way Debian (and others?) handles
> mailcap quoting.

The workaround I use right now is to modify mm-quote-arg to only quote
single quotes (using the mildly hideous '"'"' hack).  This is what
I've put in my .gnus.el:

,----
| ;;; Convince Gnus to handle single-quoted mailcap entries correctly.
| (eval-after-load 'mm-util
|               (defun mm-quote-arg (arg)
|                 "Return a version of ARG that is safe to evaluate in a shell."
|                 (let ((pos 0) new-pos accum)
|                   ;; *** bug: we don't handle newline characters properly
|                   (while (setq new-pos (string-match "'" arg pos))
|                     (push (substring arg pos new-pos) accum)
|                     (push "'\"'\"" accum)
|                     (push (list (aref arg new-pos)) accum)
|                     (setq pos (1+ new-pos)))
|                   (if (= pos 0)
|                       arg
|                     (apply 'concat (nconc (nreverse accum) (list (substring arg pos))))))))
`----

To handle double quoted entries you'll need something a bit different
(more like what is used for the non-quoted case).  If your mailcap
entries are inconsistently quoted, you're basically screwed :/.
-- 
Echelon bait:
genetic Ft. Bragg Panama Legion of Doom Serbian World Trade Center JFK
Noriega PLO Ft. Meade AK-47 $400 million in gold bullion Saddam
Hussein fissionable NORAD

`mm-quote-arg' and shell quoting in mailcap (was: Shouldn't...)

[Toby Speight]

0> In article <87r97vp9vr.fsf@worldonline.dk>,
0> Rene H. Larsen <URL:mailto:rhl@traceroute.dk> ("Rene") wrote:

Rene> The workaround I use right now is to modify mm-quote-arg to only
Rene> quote single quotes (using the mildly hideous '"'"' hack).  This
Rene> is what I've put in my .gnus.el:
Rene>
Rene> ,----
Rene> | ;;; Convince Gnus to handle single-quoted mailcap entries correctly.
Rene> | (eval-after-load 'mm-util
Rene> |               (defun mm-quote-arg (arg)
Rene> |                 "Return a version of ARG that is safe to evaluate in a shell."
Rene> |                 (let ((pos 0) new-pos accum)
Rene> |                   ;; *** bug: we don't handle newline characters properly
Rene> |                   (while (setq new-pos (string-match "'" arg pos))
Rene> |                     (push (substring arg pos new-pos) accum)
Rene> |                     (push "'\"'\"" accum)
Rene> |                     (push (list (aref arg new-pos)) accum)
Rene> |                     (setq pos (1+ new-pos)))
Rene> |                   (if (= pos 0)
Rene> |                       arg
Rene> |                     (apply 'concat (nconc (nreverse accum) (list (substring arg pos))))))))
Rene> `----

I use ordinary \' like this

dot-gnus.el> (eval-after-load "mm-util" (quote
dot-gnus.el> (defun  mm-quote-arg (arg)
dot-gnus.el>   "Return a version of ARG that is safe to evaluate in a shell."
dot-gnus.el>   (let ((pos 0) new-pos accum)
dot-gnus.el>     (while (setq new-pos (string-match "'" arg pos))
dot-gnus.el>       (push (substring arg pos new-pos) accum)
dot-gnus.el>       (push "\\" accum)
dot-gnus.el>       (push (list (aref arg new-pos)) accum)
dot-gnus.el>       (setq pos (1+ new-pos)))
dot-gnus.el>     (if (= pos 0)
dot-gnus.el>         arg
dot-gnus.el>       (apply 'concat (nconc (nreverse accum) (list (substring arg pos)))))))))

WIBNI if this kind of definition was automatically selected on Debian
systems?  (or if the filenames were always translated to something
innocuous?  That's the Right Thing IMO)


Rene> To handle double quoted entries you'll need something a bit
Rene> different (more like what is used for the non-quoted case).  If
Rene> your mailcap entries are inconsistently quoted, you're basically
Rene> screwed :/.

With a SMOP, `mm-quote-arg' could parse the command up to the %s and
determine how to quote the filename.  I'll leave it as an exercise to
the reader.

Re: `mm-quote-arg' and shell quoting in mailcap (was: Shouldn't...)

[Rene H. Larsen]

Toby Speight <streapadair@gmx.net> writes:

> 0> In article <87r97vp9vr.fsf@worldonline.dk>,
> 0> Rene H. Larsen <URL:mailto:rhl@traceroute.dk> ("Rene") wrote:
> 
> Rene> The workaround I use right now is to modify mm-quote-arg to only
> Rene> quote single quotes (using the mildly hideous '"'"' hack).  This

[...]

> I use ordinary \' like this

Are you sure this actually works for file names containing single
quotes?  All the shells I have tried barf on this:

$ echo 'foo\'bar'

[...]

> WIBNI if this kind of definition was automatically selected on Debian
> systems?  (or if the filenames were always translated to something
> innocuous?  That's the Right Thing IMO)

I agree.  For systems where the system mailcap is known to use
consistent quoting, it would be really nice if Gnus would
automagically choose the correct version of mm-quote-arg.
-- 
Echelon bait:
Waco, Texas Ft. Bragg Bosnia South Africa Albania SDI Delta Force
plutonium Soviet Marxist DES Mossad constitution Clinton Rule Psix

Re: `mm-quote-arg' and shell quoting in mailcap

[Toby Speight]

0> In article <87sns8oxpu.fsf_-_@delivery.cam.eu.citrix.com>,
0> Toby Speight <URL:mailto:streapadair@gmx.net> ("Toby") wrote:

Toby> I use ordinary \' like this ...


0> In article <873dk7nyxl.fsf@worldonline.dk>,
0> Rene H. Larsen <URL:mailto:rhl@traceroute.dk> ("Rene") wrote:

Rene> Are you sure this actually works for file names containing single
Rene> quotes?  All the shells I have tried barf on this:
Rene>
Rene> $ echo 'foo\'bar'

Er, you're right - I hadn't properly tested it.  Sorry for the
misinformation, and thanks for putting me right.

Re: `mm-quote-arg' and shell quoting in mailcap (was: Shouldn't...)

[Greg Stark]

"Rene H. Larsen" <rhl@traceroute.dk> writes:

> > WIBNI if this kind of definition was automatically selected on Debian
> > systems?  (or if the filenames were always translated to something
> > innocuous?  That's the Right Thing IMO)
> 
> I agree.  For systems where the system mailcap is known to use
> consistent quoting, it would be really nice if Gnus would
> automagically choose the correct version of mm-quote-arg.

Wouldn't the right thing to do be to check if the %s is surrounded by single
quotes before quoting the arguments? Otherwise you're going to run into a
problem if your home directory is shared across different systems... And since
the worst case problem you run into is a security hole I would suggest the
most conservative logic, namely always quote unless you can verify the mailcap
rule is safe without quoting.


-- 
greg

Re: Shouldn't Gnus (er, W3) inline related images in <img src=cid:...>?

[François Pinard]

[Rene H. Larsen]

> The workaround I use right now is to modify mm-quote-arg to only quote
> single quotes (using the mildly hideous '"'"' hack).

I use a  '\''  hack, which is only 0.8 hideous, counting 1.0 for above! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard