--- Comment #9 from Mikhail T. <> ---
(In reply to Eugene Grosbein from comment #8)
> Cron jobs are not supposed to spit binary data to standard output.
One can just as well argue, cron-jobs aren't supposed to spit /anything/ to
standard output. But they do and that output has been emailed by cron for
decades. If my job fetches a text-file from a web-server every day, I can rely
on cron to e-mail it to me -- why should the logic be any different, if I
switched to fetching a JPG?

And it is not necessarily binary -- what if the output is a CSV or HTML? There
is no good reason not to mark it correctly, indeed, it is a bug not to...

> also don't think that libmagic overhead should be made default
What overhead? Compared to mailing something in the first place -- which
involves multiple fork-ing, exec-ing, and network traffic, consulting a few
local files in-process is nothing -- and cron-jobs aren't happening millions of
times per minute...

Maybe, it should be possible for the cronjob-owner to explicitly set the
mime-type per job. But, if they don't, cron should do the guessing for them.
Unless compiled without the functionality at all, which should, as you
suggested, be an option (WITHOUT_MAGIC).

> fixed value like CONTENT_TYPE=fixed:"text/plain; charset=utf-8"
"text/plain" is the default for messages with Mime-Type set and thus does not
need to be explicitly set at all. Except for when it is wrong.

BTW, my default for text is KOI8-U so right there some other logic would be
necessary to set the header correctly. Better leave it to libmagic and be
consistent with other software (like Apache's mod_magic).

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to