Re: Patch to add -E option to mailx

Eygene Ryabinkin <rea-fbsd@...> wrote:

> I made mailx to respect -E in every mode,

Fine. I have integrated your patch. Unfortunately, the
CVS server is currently offline (see the SourceForge
site status page at <http://sourceforge.net/docs/A04>);
I will commit the code as soon as the server becomes
accessible again.

Note that with the code you submitted, attachments as
specified with the -a option are not relevant when
determining whether to send a message with -E or not.
I accept it this way since it might be useful for cron
script usage, and have stated it in the documentation.
However, I am not sure if you intended it or not. If
not, please wait until the new revision is available
in the CVS repository, and supply a new patch for it.

> since original Berkeley mail does it.

I doubt that anything done by one of today's BSD teams
qualifies as "original Berkeley". This term makes more
sense if restricted to code written by the historic
CSRG team at UCB.

I accept this functionality since it is clearly quite
useful for cron scripts. However, this should not be
misunderstood such that I would accept anything just
because some other variant of Berkeley Mail has it.

Re: Patch to add -E option to mailx

Gunnar, good day.

Mon, Oct 01, 2007 at 02:52:54PM +0200, Gunnar Ritter wrote:
> Fine. I have integrated your patch. Unfortunately, the
> CVS server is currently offline (see the SourceForge
> site status page at <http://sourceforge.net/docs/A04>);
> I will commit the code as soon as the server becomes
> accessible again.

OK, thank you!

> Note that with the code you submitted, attachments as
> specified with the -a option are not relevant when
> determining whether to send a message with -E or not.
> I accept it this way since it might be useful for cron
> script usage, and have stated it in the documentation.
> However, I am not sure if you intended it or not.

I forgot about attachments, sorry.  Will try to address this
issue, thanks for spotting this.

> > since original Berkeley mail does it.
> 
> I doubt that anything done by one of today's BSD teams
> qualifies as "original Berkeley". This term makes more
> sense if restricted to code written by the historic
> CSRG team at UCB.

Yes, I was incorrect.  I thought that '-E' existed in the CSRG's
mail, but I was naive since '-E' came to FreeBSD from NetBSD

Re: Patch to add -E option to mailx

Eygene Ryabinkin <rea-fbsd@...> wrote:

> Mon, Oct 01, 2007 at 02:52:54PM +0200, Gunnar Ritter wrote:
> > Fine. I have integrated your patch. Unfortunately, the
> > CVS server is currently offline (see the SourceForge
> > site status page at <http://sourceforge.net/docs/A04>);
> > I will commit the code as soon as the server becomes
> > accessible again.
>
> OK, thank you!

The server is now online again and I have committed the
code. It should be publicly available very soon.

> > Note that with the code you submitted, attachments as
> > specified with the -a option are not relevant when
> > determining whether to send a message with -E or not.
> > I accept it this way since it might be useful for cron
> > script usage, and have stated it in the documentation.
> > However, I am not sure if you intended it or not.
>
> I forgot about attachments, sorry.  Will try to address this
> issue, thanks for spotting this.

As said, it is at your discretion. But it might actually
make sense to ignore attachments in this case, as e.g.
for "if there is an error message, also attach the
configuration file", which would always be non-empty,
of course. So you should not simply change the behavior
now but first develop an argument why you prefer one

Something has broken mime-encoding

I have an web application that generates e-mails and PDF-attachements,
and uses nail to send them with the -a flag.  The attachment files were
initially created as postscript and converted using ps2pdf.

This has worked fine until several months ago (I just discovered this
now) where the PDF files are now being encoded as 

        Content-Type: application/octet-stream
        Content-Transfer-Encoding: base64

while in the past (at least as of June 23 2006) they were encoded as:

        Content-Type: application/pdf
        Content-Transfer-Encoding: base64

Saving the attachment to disk results in the correct pdf file (viewable
with acroread for example), my e-mail client (evolution) incorrectly
identifies the type of the file. 

Shouldn't the content type still be application/pdf?   Note that this
should only be the content-type so as to not to recreate the bug that
was fixed in 12.2.

David

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: Something has broken mime-encoding

David Ronis <ronis@...> wrote:

> I have an web application that generates e-mails and PDF-attachements,
> and uses nail to send them with the -a flag.  The attachment files were
> initially created as postscript and converted using ps2pdf.
>
> This has worked fine until several months ago (I just discovered this
> now) where the PDF files are now being encoded as 
>
>         Content-Type: application/octet-stream
>         Content-Transfer-Encoding: base64
>         
> while in the past (at least as of June 23 2006) they were encoded as:
>
>         Content-Type: application/pdf
>         Content-Transfer-Encoding: base64

I have no problem to send a PDF document with the
appropriate content-type header field. Maybe one of
your mime.types files has changed and is lacking the
correct

    application/pdf        pdf

entry now?

	Gunnar

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.

Re: Something has broken mime-encoding

Hi Gunnar, 

Thanks for the quick reply.  Are you saying that when you use nail to
send a .pdf file, the resulting Content-Type is application/pdf?  Or are
you saying that your mail reader can figure it out anyway (e.g., by
doing some sort of content sniffing or looking at the filename and using
some built in mime-types)?

David

On Mon, 2007-10-08 at 01:22 +0200, Gunnar Ritter wrote:
> David Ronis <ronis@...> wrote:
> 
> > I have an web application that generates e-mails and PDF-attachements,
> > and uses nail to send them with the -a flag.  The attachment files were
> > initially created as postscript and converted using ps2pdf.
> >
> > This has worked fine until several months ago (I just discovered this
> > now) where the PDF files are now being encoded as 
> >
> >         Content-Type: application/octet-stream
> >         Content-Transfer-Encoding: base64
> >         
> > while in the past (at least as of June 23 2006) they were encoded as:
> >
> >         Content-Type: application/pdf
> >         Content-Transfer-Encoding: base64
> 
> I have no problem to send a PDF document with the
> appropriate content-type header field. Maybe one of

Re: Something has broken mime-encoding

David Ronis <ronis@...> wrote:

> Thanks for the quick reply.  Are you saying that when you use nail to
> send a .pdf file, the resulting Content-Type is application/pdf?  Or are
> you saying that your mail reader can figure it out anyway (e.g., by
> doing some sort of content sniffing or looking at the filename and using
> some built in mime-types)?

http://heirloom.sourceforge.net/mailx/mailx.1.html#12
http://heirloom.sourceforge.net/mailx/mailx.1.html#20

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: Something has broken mime-encoding

Hi Gunnar,

Thanks for the tip.  The problem turns out to be /etc/mime.types, which
on the sender's machine was truncated for some reason (I suspect an
errant install script).  It contained only a few entries, and in
particular didn't have an 'application/pdf pdf' entry.  I merged in the
mime types that came with apache and the problem went away.

Thanks for your help.

David

On Mon, 2007-10-08 at 09:41 +0200, Gunnar Ritter wrote:
> David Ronis <ronis@...> wrote:
> 
> > Thanks for the quick reply.  Are you saying that when you use nail to
> > send a .pdf file, the resulting Content-Type is application/pdf?  Or are
> > you saying that your mail reader can figure it out anyway (e.g., by
> > doing some sort of content sniffing or looking at the filename and using
> > some built in mime-types)?
> 
> http://heirloom.sourceforge.net/mailx/mailx.1.html#12
> http://heirloom.sourceforge.net/mailx/mailx.1.html#20
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

mailx for everyday use

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
nail-devel mailing list
nail-devel@...
https://lists.sourceforge.net/lists/listinfo/nail-devel

Re: mailx for everyday use

> I would like to make script to allow me to attach a file with
> filename completion ability, without actually adding readline
> Is this possible?

I'm admittedly not a fan or bug user of attachments anyway but:

I'm not missing filename completion because I can always

(a)  use the   ~!ls foo*    escape and then the mouse (X11 or screen(1))
(b)  use the   ~!ls foo*    escape and an xterm's dabbrev feature

when using the ~ <at>  attachment escape next.

The xterm dynamic-abbreviation feature is probably little known.
It is just a few years old and, though described in most man pages by
now, seldom enabled in xxBSD or Linux distributions.  It's a compile
time option.  In addition, you need to define a key for the dabbrev
action in your ressource settings as described in the manpage.   So,
yes, it's a bit of a setup hassles, but well worth the effort.

								Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/