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
