Kevin Ryde wrote: > Michael Stone writes: > > I'm not sure why this would be useful.
I don't understand how mailcap and mime types are related to coreutils. I don't think coreutils should own a mailcap entry. > Currently "run-mailcap --action=cat" cannot cat a text/plain text file > but adding a mailcap entry will let it work. What mail-user-agent are you using where this configuration is advantageous? I have used many MUAs over the years and this hasn't ever been needed. Therefore I am skeptical of the proposal. I can certainly use my MUA to perform actions on various sorts of text/* attachments without this mailcap entry. I am therefore suspicious that this should actually be a wishlist enhancment request against your MUA. What specific action are you trying to do with what mailer that currently isn't working for you? > > Why wouldn't you just pipe the file to a pager and avoid the > > mailcap indirection? > > Primarily for genericness. If you have a mail part or file then you let > run-mailcap find a good command. The run-mailcap command is in the mime-support package. Perhaps this issue would be better discussed within the mime-support package project rather than about coreutils? It doesn't seem to me to be a coreutils issue. > But --action=cat is not for a pager, rather getting plain text to pass > on somewhere else. For text/plain this is a no-op, but that knowledge > is not built-in to run-mailcap, hence a "cat" entry. (Not hard-coding > it seems reasonable to me. Let the runner be general and add entries > expressing what various programs like "cat" can or will do. Other > programs might make use of those entries too.) The text/plain mailcap is already loaded with other entries such as on my system: text/plain; less '%s'; needsterminal text/plain; most '%s'; needsterminal text/plain; more '%s'; needsterminal text/plain; emacs23 %s; test=test -n "$DISPLAY" text/plain; emacs24 %s; test=test -n "$DISPLAY" text/plain; gedit --new-document %s; test=test -n "$DISPLAY" text/plain; gobby-0.5 %s; test=test -n "$DISPLAY" text/plain; gvim -f %s; test=test -n "$DISPLAY" text/plain; leafpad %s; test=test -n "$DISPLAY" text/plain; xfview %s; test=test -n "$DISPLAY" text/plain; xfwrite %s; test=test -n "$DISPLAY" text/plain; view '%s'; edit=vim '%s'; compose=vim '%s'; test=test -x /usr/bin/vim; needsterminal text/plain; gview -f '%s'; edit=gvim -f '%s'; compose=gvim -f '%s'; test=test "$DISPLAY" != "" text/plain; view '%s'; edit=vi '%s'; compose=vi '%s'; needsterminal Those all seem more appropriate than 'cat'. > > I'd think this would be more likely to confuse people with control > > character output when they're expecting an image or somesuch. And more specifically 'cat' is not a display program. It really should be handled by a pager such as more, less or most. (And those already exist.) Or at least a program that is designed to be a display program. > Oh, images or other binaries are meant to be crunched by the mailcap > rules to plain text for this --action=cat, or at least that's the idea. > For example xlhtml can crunch an application/excel to text (via html in > its case). Or "tar" and 'unzip" offer a contents listing for tar and > zip files. I think this is definitely beyond the scope of the coreutils package. Bob
signature.asc
Description: Digital signature
