Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
On Tue, Dec 08, 2009 at 09:51:50PM +0100, Brian White wrote: I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Yes, could you please do so. That would be the best since as you say cat isn't defined in the first place and at least some people need canonical way to run run-mailcap as filter, where cat fits perfectly imho. Done in v3.48, just uploaded. Thanks, now it works. Although I think the man page should be corrected as well. Something like this? diff -up ./run-mailcap.man.kirr ./run-mailcap.man --- ./run-mailcap.man.kirr 2009-12-03 22:41:28.0 +0300 +++ ./run-mailcap.man 2009-12-10 12:32:32.0 +0300 @@ -58,7 +58,7 @@ All options are in the form --opt=val Performs the specified action on the files. Valid actions are .IR view , .IR cat -(like view but never paged) , +(uses only copiousoutput rules and sends output to STDOUT) , .IR compose , .IR composetyped , .I edit Kirill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Yes, could you please do so. That would be the best since as you say cat isn't defined in the first place and at least some people need canonical way to run run-mailcap as filter, where cat fits perfectly imho. Done in v3.48, just uploaded. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
On Thu, Dec 03, 2009 at 10:07:10PM +0100, Brian White wrote: [...] I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Yes, could you please do so. That would be the best since as you say cat isn't defined in the first place and at least some people need canonical way to run run-mailcap as filter, where cat fits perfectly imho. Just my 2 коп, Кирилл -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I too think, --action=cat should ignore X viewers. After all, original --action=cat use case (as requested by me btw in #526690) was to use it as canonical filter. So _filtering_ functionality was assumed by --action=cat, and otherwise to me cat seems to be useless because we have --action=view. For my needs I created an extra script 8 astextplain #!/bin/sh unset DISPLAY run-mailcap --action=cat $* 8 instead of just using `run-mailcap --action=cat` where appropriate. What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. That makes sense, but I can think of no generic way to know if it's an interactive viewer. I suppose we can say that between $DISPLAY and needsterminal that covers almost all possibilities. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. That would be my preference too. To obtain the functionality as Brian implemented it, I'd probably rather something like run-mailcap --action=view --nopager since it's such a minor change from the default view action. However that isn't interesting to me so I didn't implement it. That would be an easier change. Plus, it would mean not violating the RFC by adding a new action. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. That makes sense, but I can think of no generic way to know if it's an interactive viewer. I thought copiousoutput meant non-interactive stdout. Am I mistaken? I suppose we can say that between $DISPLAY and needsterminal that covers almost all possibilities. Unfortunately I know of at least one filter (unoconv) that connects to the X server (to access the openoffice server, I believe). So if we want that to work, it's not really an option to unset DISPLAY prior to running mailcap tests. Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. That makes sense, but I can think of no generic way to know if it's an interactive viewer. I thought copiousoutput meant non-interactive stdout. Am I mistaken? copiousoutput indicates that the program produces a lot of output and should be fed into a pager program so as to not overwhelm the user. I've added a --nopager option in the latest upload. I suppose we can say that between $DISPLAY and needsterminal that covers almost all possibilities. Unfortunately I know of at least one filter (unoconv) that connects to the X server (to access the openoffice server, I believe). So if we want that to work, it's not really an option to unset DISPLAY prior to running mailcap tests. I've left cat in place though it now unsets DISPLAY. There's no perfect solution, I'm afraid. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Brian, I appreciate your maintainership of run-mailcap, but first you take a long time to reply then you upload immediately without waiting for feedback on your comments. You have a couple people here interested in testing and providing feedback prior to release... Brian White wrote: [Thu Dec 03 2009, 03:14:32PM EST] I thought copiousoutput meant non-interactive stdout. Am I mistaken? copiousoutput indicates that the program produces a lot of output and should be fed into a pager program so as to not overwhelm the user. I've added a --nopager option in the latest upload. So by strict RFC interpretation, a mailcap rule specifying copiousoutput implies non-interactive output on stdout, however a mailcap rule lacking copiousoutput does not strictly imply the opposite. Unfortunately this strict interpretation of the flag isn't useful for a couple reasons: 1. there's no way for the mailcap rule to know the length of the output since it depends on the input. 2. the use of a pager depends on the size of the output compared to the size of the terminal, but the mailcap doesn't know the size of the terminal either. This is probably why mutt deviates from strict RFC for the copiousoutput flag, meaning that mutt uses the flag to find rules that generate non-interactive stdout. Unfortunately I know of at least one filter (unoconv) that connects to the X server (to access the openoffice server, I believe). So if we want that to work, it's not really an option to unset DISPLAY prior to running mailcap tests. I've left cat in place though it now unsets DISPLAY. There's no perfect solution, I'm afraid. Thanks for trying to provide a solution. I understand the reasons for your choices, but unfortunately the various changes you've made fail to provide a method of achieving the result I want (which depends on copiousoutput) so I'll have to continue to maintain my fork. Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I thought copiousoutput meant non-interactive stdout. Am I mistaken? copiousoutput indicates that the program produces a lot of output and should be fed into a pager program so as to not overwhelm the user. I've added a --nopager option in the latest upload. So by strict RFC interpretation, a mailcap rule specifying copiousoutput implies non-interactive output on stdout, however a mailcap rule lacking copiousoutput does not strictly imply the opposite. No, it doesn't. You can't win here. Mailcap was written with the intent of user interaction, not for filtering. No solution is going to work in all situations unless you deviate from the RFC. Unfortunately this strict interpretation of the flag isn't useful for a couple reasons: 1. there's no way for the mailcap rule to know the length of the output since it depends on the input. 2. the use of a pager depends on the size of the output compared to the size of the terminal, but the mailcap doesn't know the size of the terminal either. This is probably why mutt deviates from strict RFC for the copiousoutput flag, meaning that mutt uses the flag to find rules that generate non-interactive stdout. Sure, but you can't depend on the people writing the mailcap entries to flag their programs that way unless you want to create a new RFC or make it Debian policy. I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Brian White wrote: [Thu Dec 03 2009, 04:07:10PM EST] I thought copiousoutput meant non-interactive stdout. Am I mistaken? copiousoutput indicates that the program produces a lot of output and should be fed into a pager program so as to not overwhelm the user. I've added a --nopager option in the latest upload. So by strict RFC interpretation, a mailcap rule specifying copiousoutput implies non-interactive output on stdout, however a mailcap rule lacking copiousoutput does not strictly imply the opposite. No, it doesn't. You can't win here. I'm confused. I wasn't intending to argue with you above. I'll try again. First, here's the definition of copiousoutput from RFC 1524: The copiousoutput field indicates that the output from the view-command will be an extended stream of output, and is to be interpreted as advice to the UA (User Agent mail-reading program) that the output should be either paged or made scrollable. Note that it is probably a mistake if needsterminal and copiousoutput are both specified. and I was inferring the following from that: 1. A mailcap run specifying copiousoutput will generate non-interactive stdout. It can't be interactive if a pager is involved, because the pager steals control of the terminal. And it must be on stdout in order for the pager to receive it. Right so far? 2. However, unfortunately the inclusion of extended in the definition above means that we can't trust *all* rules generating non-interactive stdout to include the copiousoutput flag. There might be some that generate non-interactive stdout which don't include the flag because the output is short, as judged by the author of the rule. That is what I intended by what I wrote above. I was intending to lay the groundwork for explaining why interpreting this strictly isn't useful. Mailcap was written with the intent of user interaction, not for filtering. No solution is going to work in all situations unless you deviate from the RFC. *nod* Unfortunately this strict interpretation of the flag isn't useful for a couple reasons: 1. there's no way for the mailcap rule to know the length of the output since it depends on the input. 2. the use of a pager depends on the size of the output compared to the size of the terminal, but the mailcap doesn't know the size of the terminal either. This is probably why mutt deviates from strict RFC for the copiousoutput flag, meaning that mutt uses the flag to find rules that generate non-interactive stdout. Sure, but you can't depend on the people writing the mailcap entries to flag their programs that way unless you want to create a new RFC or make it Debian policy. I agree, however you can at least depend on copiousoutput rules as working the way we need for cat without stooping to questionable tricks like unsetting $DISPLAY I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Personally I think that would be the best, along with refraining from unsetting $DISPLAY. (In fact, it's exactly what I suggested in opening this bug.) Thanks, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I too think, --action=cat should ignore X viewers. After all, original --action=cat use case (as requested by me btw in #526690) was to use it as canonical filter. So _filtering_ functionality was assumed by --action=cat, and otherwise to me cat seems to be useless because we have --action=view. For my needs I created an extra script 8 astextplain #!/bin/sh unset DISPLAY run-mailcap --action=cat $* 8 instead of just using `run-mailcap --action=cat` where appropriate. What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. Thanks beforehand, Kirill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Kirill Smelkov wrote: [Mon Oct 12 2009, 09:40:11AM EDT] I too think, --action=cat should ignore X viewers. After all, original --action=cat use case (as requested by me btw in #526690) was to use it as canonical filter. So _filtering_ functionality was assumed by --action=cat, and otherwise to me cat seems to be useless because we have --action=view. I tend to agree that the current implementation of --action=cat is not useful. For my needs I created an extra script 8 astextplain #!/bin/sh unset DISPLAY run-mailcap --action=cat $* 8 instead of just using `run-mailcap --action=cat` where appropriate. This has the unfortunate effect of avoiding translators that require an X connection, for example unoconv. That's why I finally realized this method wasn't right and I opened this bug. What are use-cases for current cat behaviour? If there is none besides being used as a filter, let's please make it ignore interactive viewers and just pipe the result to stdout. That would be my preference too. To obtain the functionality as Brian implemented it, I'd probably rather something like run-mailcap --action=view --nopager since it's such a minor change from the default view action. However that isn't interesting to me so I didn't implement it. Kirill, if you're interested in trying it, I've attached my version of run-mailcap which includes my patches from #533721, #533722 and #533723. Presently I have this in my /usr/local/bin to override the default installation. Regards, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Whoops, forgot to attach it. Here it is.
#! /usr/bin/perl
###
#
# Run-Mailcap: Run a program specified in the mailcap file based on a mime
# type.
#
# Written by Brian White bcwh...@pobox.com
# This file has been placed in the public domain (the only true free).
#
###
$debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
$norun=0;
$etcmimetyp=/etc/mime.types;
$shrmimetyp=/usr/share/etc/mime.types;
$locmimetyp=/usr/local/etc/mime.types;
$usrmimetyp=$ENV{HOME}/.mime.types;
$xtermprgrm=/usr/bin/x-terminal-emulator; # xterm?
$defmimetyp=application/octet-stream;
$quotedsemi=chr(255);
$quotedprct=chr(254);
$retcode=0;
%patterntypes =
(
'(^|/)crontab[^/]+$' = 'text/x-crontab',
#'
'/man\d*/' = 'application/x-troff-man',
#'
'\.\d[^\.]*$' = 'application/x-troff-man',
#'
);
sub Usage {
my($error) = @_;
print STDERR $error,\n\n if $error;
print STDERR Use: $0 --action=VAL [--debug] [MIME-TYPE:[ENCODING:]]FILE
[...]\n\n;
print STDERR Options:\n;
print STDERR actionspecify what action to do on these files
(default=view)\n;
print STDERR debug be verbose about what's going on\n;
print STDERR norun just print but don't execute the command
(useful with --debug)\n;
print STDERR \n;
print STDERR Mime-Type:\n;
print STDERR any standard mime type designation in the form
class/subtype -- if\n;
print STDERR not specified, it will be determined from the filename
extension\n\n;
print STDERR Encoding:\n;
print STDERR how the file (and type) has been encoded (only \gzip\,
\bzip\, \bzip2\\n;
print STDERR and \compress\ are supported) -- if not specified, it
will be determined\n;
print STDERR from the filename extension\n\n;
exit ($error ? 1 : 0);
}
sub EncodingForFile {
my($file) = @_;
my $encoding;
if ($file =~ m/\.gz$/) { $encoding = gzip; }
if ($file =~ m/\.bz$/) { $encoding = bzip; }
if ($file =~ m/\.bz2$/) { $encoding = bzip2; }
if ($file =~ m/\.Z$/) { $encoding = compress; }
print STDERR - file \$file\ has encoding \$encoding\\n if $debug
$encoding;
return $encoding;
}
sub ReadMimetypes {
my($file) = @_;
return unless -r $file;
print STDERR - Reading mime.types file \$file\...\n if $debug;
open(MIMETYPES,$file) || die Error: could not read \$file\ -- $!\n;
while (MIMETYPES) {
chomp;
s/\#.*$//;
next if (m/^\s*$/);
$_=lc($_);
my($type,@exts) = split;
foreach (@exts) {
$mimetypes{$_} = $type unless exists $mimetypes{$_};
}
}
close MIMETYPES;
}
sub ReadMailcap {
my($file) = @_;
my $line = ;
return unless -r $file;
print STDERR - Reading mailcap file \$file\...\n if $debug;
open(MAILCAP,$file) || die Error: could not read \$file\ -- $!\n;
while (MAILCAP) {
chomp;
s/^\s+// if $line;
$line .= $_;
next unless $line;
if ($line =~ m/^\s*\#/) {
$line = ;
next;
}
if ($line =~ m/\\$/) {
$line =~ s/\\$//;
} else {
$line =~ s/\\;/$quotedsemi/go;
$line =~ s/\\%/$quotedprct/go;
push @mailcap,$line;
$line = ;
}
}
close MAILCAP;
}
sub TempFile {
my($template) = @_;
my($cmd,$head,$tail,$tmpfile);
$template = unless (defined $template);
($head,$tail) = split(/%s/,$template,2);
# $tmpfile = POSIX::tmpnam($name);
# unlink($tmpfile);
$cmd = tempfile --mode=600;
$cmd .= --prefix $head if $head;
$cmd .= --suffix $tail if $tail;
$tmpfile = `$cmd`;
chomp($tmpfile);
# $tmpfile = $ENV{TMPDIR};
# $tmpfile = /tmp unless $tmpfile;
# $tmpfile.= /$name;
# unlink($tmpfile);
return $tmpfile;
}
sub SaveStdin {
my($match) = @_;
my($tmpfile,$amt,$buf);
$tmpfile = $1 if ($match =~ m/nametemplate=(.*?)\s*($|;)/);
$tmpfile = TempFile($tmpfile);
open(TMPFILE,$tmpfile) || die Error: could not write \$tmpfile\ --
$!\n;
do {
$amt = read(STDIN,$buf,102400);
print TMPFILE $buf if $amt;
} while ($amt != 0);
close(TMPFILE);
return $tmpfile;
}
sub DecodeFile {
my($efile,$encoding,$action) = @_;
my($file,$res);
$file = $efile;
$file =~ s!^.*/!!; # remove leading directories
$file =~ s!\.[^\.]*$!!; # remove encoding extension
$file =~ s!^\.?[^\.]*!%s!; # replace name with placeholder
$file = undef if ($efile eq '-');
my $tmpfile = TempFile($file);
print STDERR - decoding \$efile\ as \$tmpfile\\n if $debug;
# unlink($tmpfile); # should still be acceptable for compose output
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Hi Brian, I must be missing the point of --action=cat. Its name seems to imply non-interactive stdout, but it will still run X-based viewers and needsterminal viewers. The latter seems especially strange since the user probably doesn't want an interactive curses viewer if they used --action=cat to avoid the pager. I don't mind changing it to ignore X viewers or needsterminal viewers, but those that can be the case even when copiousoutput is not specified. How did you feel I was trying to shoe-horn extra functionality? --action=filter adds a new type of functionality. Filtering is not necessarily the same as viewing. Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I don't agree. Cat is like view but without a pager. To have it choose otherwise would be confusing. The mailcap system is pretty fragile in general; I don't think you should try to shoe-horn extra functionality this way. Instead, create a filter action in the rules you want and use --action=filter (or similar). Hi Brian, I must be missing the point of --action=cat. Its name seems to imply non-interactive stdout, but it will still run X-based viewers and needsterminal viewers. The latter seems especially strange since the user probably doesn't want an interactive curses viewer if they used --action=cat to avoid the pager. I don't mind writing the patch to use --action=filter. I just can't think of a scenario where --action=cat is interesting in that case. How did you feel I was trying to shoe-horn extra functionality? Thanks, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
I came to the conclusion that --action=cat should ignore mailcap entries other than copiousoutput. I don't agree. Cat is like view but without a pager. To have it choose otherwise would be confusing. The mailcap system is pretty fragile in general; I don't think you should try to shoe-horn extra functionality this way. Instead, create a filter action in the rules you want and use --action=filter (or similar). Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
Package: mime-support Version: 3.46-1 Severity: normal I've observed that there's no way to differentiate between calling run-mailcap to view an file (for example running ooffice) and calling run-mailcap to translate a file to text/plain (for example for viewing in mutt). The only indicator available is to unset the DISPLAY variable and masquerade the terminal, but that's inherently flawed because some translators (unoconv for example) need an X connection even when they're just converting to text/plain. I came to the conclusion that --action=cat should ignore mailcap entries other than copiousoutput. Consider the following example mailcap entries: text/html; firefox file://%s ; nametemplate=%s.html ; test=test -n $DISPLAY which firefox /dev/null 21 text/html; w3m file://%s ; nametemplate=%s.html ; needsterminal ; test=which w3m /dev/null 21 text/html; w3m -dump file://%s ; nametemplate=%s.html ; copiousoutput ; test=which w3m /dev/null 21 In this case, what if one wants to dump the rendered output to stdout? No-can-do with run-mailcap except with silly workarounds: $ env -u DISPLAY run-mailcap --action=cat /tmp/foo.html | cat What we really want is for --action=cat to intentionally select the copiousoutput entry. I'll follow up with a patch to fix this. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 5.03-1 Determines file type using magic mime-support suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
