Hey folks,
I am seeking the ability to invoke a command on a MIME attachment
which is not . Simple example: on a PNG
file might open xview with the temporary file, but sometimes I'd
like to load an attachment (the temporary file) in Gimp to be able
to edit and save-as to somewhere else.
Unfortun
On 24Apr2015 17:35, martin f krafft wrote:
I am seeking the ability to invoke a command on a MIME attachment
which is not . Simple example: on a PNG
file might open xview with the temporary file, but sometimes I'd
like to load an attachment (the temporary file) in Gimp to be able
to edit and sa
also sprach Cameron Simpson [2015-04-25 01:24 +0200]:
> I wrap all my mailcap commands with my apphelper script, which
> itself is wrapped in my shorter-named "ah" script. My mailcaps
> look like this:
>
> application/pdf; ah %s -1 xpdf; gui
> image/jpg; ah %s -1 xv; gui
> image/tiff; ah %s -1
On 25Apr2015 09:03, martin f krafft wrote:
also sprach Cameron Simpson [2015-04-25 01:24 +0200]:
I wrap all my mailcap commands with my apphelper script, which
itself is wrapped in my shorter-named "ah" script. My mailcaps
look like this:
application/pdf; ah %s -1 xpdf; gui
image/jpg; ah %s
also sprach Cameron Simpson [2015-04-26 01:10 +0200]:
> So I go to the attachment view in mutt. Press on the attachment,
> which runs apphelper (from mailcap).
> […]
> so pressing ran apphelper which ran "xv" immediately. After quitting
> "xv", I get the save prompt.
Right, this is nice. But I
On 26Apr2015 10:25, martin f krafft wrote:
also sprach Cameron Simpson [2015-04-26 01:10 +0200]:
So I go to the attachment view in mutt. Press on the attachment,
which runs apphelper (from mailcap).
[…]
so pressing ran apphelper which ran "xv" immediately. After quitting
"xv", I get the save
also sprach Cameron Simpson [2015-04-26 12:26 +0200]:
> My mailcap makes apphelper the handler for most file types, and
> supplies apphelper the default "end" viewer. Apphelper runs the
> viewer (asking first by default) and offers to save the file, and
> accepts "!shell command" at its prompts.
>
On 26Apr2015 20:06, martin f krafft wrote:
also sprach Cameron Simpson [2015-04-26 12:26 +0200]:
My mailcap makes apphelper the handler for most file types, and
supplies apphelper the default "end" viewer. Apphelper runs the
viewer (asking first by default) and offers to save the file, and
acc
also sprach Cameron Simpson [2015-04-26 22:54 +0200]:
> Apphelper first asks whether to view the file, offering the
> supplied view command in [square brackets] as the default. Pressing
> return or entering "y" or "yes' accepts this default and runs the
> viewer. Entering "n" or "no" skips r
On 27Apr2015 09:23, martin f krafft wrote:
also sprach Cameron Simpson [2015-04-26 22:54 +0200]:
Apphelper first asks whether to view the file, offering the
supplied view command in [square brackets] as the default. Pressing
return or entering "y" or "yes' accepts this default and runs the
What I do in similar situations is pipe the attachment to a helper (I
call it muttfilter) that accepts as first argument a file name, as
second argument a command name and as further arguments any options to
that command. The helper copies the attachment to the filename, runs
the command with all i
also sprach Luis Mochan [2015-04-28 04:36 +0200]:
> What I do in similar situations is pipe the attachment to a helper
> (I call it muttfilter) that accepts as first argument a file name,
Oh, but now you need a different pipe depending on the file type,
e.g. for PDF and PNG. I don't really want t
> Oh, but now you need a different pipe depending on the file type,
> e.g. for PDF and PNG. I don't really want that as mailcap already
> handles this.
I use it only when I want to override mailcap for whatever
reason, and then I specify the program I want to use in the pipe
command. Otherwise I si
also sprach Cameron Simpson [2015-04-28 04:17 +0200]:
> I do not properly understand versus .
> I would appreciate someone else chiming in here.
I think the difference is that tries to render inline
(e.g. text/plain) and only resorts to run-mailcap when it has not
internal viewer. skips the in
also sprach Cameron Simpson [2015-04-28 04:17 +0200]:
> Sounds like a job for a mutt macro. A first cut would be to write
> a macro which pointed $mailcap_path at a different mailcap file,
> then ran view-attach, then restored the old value.
Yes! This idea led me to a working solution^W hack:
15 matches
Mail list logo
