4:40 p.m.
I recently updated my TMDA (http://tmda.sourceforge.net/)
installation. Due to changes in TMDA and an ancient Exim
misconfiguration, Exim thought TMDA was attempting an illegal relay,
refused the connection, and the messages got dropped on the floor.
Nothing hugely important---but by the time I realized that they
weren't being sent out, I was doing usenet and Gnus had recycled all
the buffers. :-(
I accused TMDA:
> The big problem is that with the outgoing mail now going to
> port 25, somehow all my outgoing mail went to a bit bucket.
> For some reason, exim decided that mail sent via TMDA was
> coming from an external site and refused to relay. The
> messages were dropped on the floor, with no logs or copies kept
> by TMDA AFAICS. That looks like TMDA's bad to me.
And the TMDA maintainer replied:
tmda> Nope, that's a bug in Gnus, which someone really needs to
tmda> report. If `sendmail-program' exits non-zero, Gnus silently
tmda> fails instead of stopping, and displaying the error. To see
tmda> how gross this error is, create an empty file
tmda> (/tmp/emptyfile), chmod 755, and in your .gnus:
tmda> (setq sendmail-program "/tmp/emptyfile")
tmda> Then try sending some messages and watch them happily hit
tmda> the bit-bucket.
tmda> Most other MUAs handle this situation correctly (VM, Pine,
tmda> mutt, mailx, etc.).
So I'm reporting it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
5:33 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
tmda> Nope, that's a bug in Gnus, which someone really
needs to
tmda> report. If `sendmail-program' exits non-zero, Gnus silently
tmda> fails instead of stopping, and displaying the error. To see
tmda> how gross this error is, create an empty file
tmda> (/tmp/emptyfile), chmod 755, and in your .gnus:
tmda> (setq sendmail-program "/tmp/emptyfile")
tmda> Then try sending some messages and watch them happily hit
tmda> the bit-bucket.
tmda> Most other MUAs handle this situation correctly (VM, Pine,
tmda> mutt, mailx, etc.).
So I'm reporting it.
This is probably a mail-lib bug (sendmail.el) and not a gnus bug, so I
looked at it. This patch should fix it, does it?
--- sendmail.el.~1.16.~ Fri Mar 15 22:19:13 2002
+++ sendmail.el Tue Jun 4 18:29:36 2002
＠＠ -841,7 +841,7 ＠＠
(require 'mail-utils)
(let ((errbuf (if mail-interactive
(generate-new-buffer " sendmail errors")
- 0))
+ nil))
(tembuf (generate-new-buffer " sendmail temp"))
(case-fold-search nil)
(coding (and (local-variable-p 'buffer-file-coding-system
6:12 a.m.
The following message is a courtesy copy of an article
that has been posted to gnus.gnus-bug as well.
Simon Josefsson <jas(a)extundo.com> writes:
I looked at it. This patch should fix it, does it?
No, it doesn't. The strange thing is that this bug should have
already been fixed? See:
http://list-archive.xemacs.org/xemacs-patches/199811/msg00000.html
--
(http://tmda.sourceforge.net/)
9:16 a.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
Simon Josefsson <jas(a)extundo.com> writes:
> I looked at it. This patch should fix it, does it?
No, it doesn't.
Hm, `call-process-region' doesn't return anything useful when this
happens:
(setq sendmail-program "/tmp/emptyfile")
"/tmp/emptyfile"
(call-process-region (point-min) (point-max) sendmail-program nil nil nil)
0
How can this be separated from a successful invokation?
Emacs seem to have the same problem, btw.
The strange thing is that this bug should have already been fixed?
See:
http://list-archive.xemacs.org/xemacs-patches/199811/msg00000.html
It was fixed in 1.3, but reverted in 1.4.
revision 1.4
date: 1999/02/01 13:32:33; author: steveb; state: Exp; lines: +2 -2
Add pop3.el, fix sendmail delay bug
----------------------------
revision 1.3
date: 1998/12/10 14:37:55; author: steveb; state: Exp; lines: +40 -26
Sendmail-send-it error return fix
----------------------------
9:49 a.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> "Jason R. Mastaler" <jason(a)mastaler.com> writes:
> Simon Josefsson <jas(a)extundo.com> writes:
>
>> I looked at it. This patch should fix it, does it?
> No, it doesn't.
Simon> Hm, `call-process-region' doesn't return anything useful
Simon> when this happens:
Jason's example is bogus here; the invocation of /tmp/emptyfile
succeeds! (At least on Linux, under ash, bash, and csh.) Dunno what
a POSIX shell is supposed to do in this case....
(let ((sendmail-program "/tmp/emptyfile"))
(call-process-region (point-min) (point-max) sendmail-program nil nil nil))
Put "#!/bin/sh\nexit 1\n" in /tmp/exit1, and try again.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
11:16 a.m.
On 5 Jun 2002, Stephen J. Turnbull wrote:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> "Jason R. Mastaler" <jason(a)mastaler.com> writes:
>> Simon Josefsson <jas(a)extundo.com> writes:
>>
>>> I looked at it. This patch should fix it, does it?
>> No, it doesn't.
Simon> Hm, `call-process-region' doesn't return anything useful
Simon> when this happens:
Jason's example is bogus here; the invocation of /tmp/emptyfile
succeeds! (At least on Linux, under ash, bash, and csh.) Dunno what
a POSIX shell is supposed to do in this case....
(let ((sendmail-program "/tmp/emptyfile"))
(call-process-region (point-min) (point-max) sendmail-program nil nil nil))
Put "#!/bin/sh\nexit 1\n" in /tmp/exit1, and try again.
I agree, the example was bogus. It seems rather weird to be able to
exec() a 0b file though.
However, the patch should still be applied, I think, because otherwise you
don't get any return value at all. Try running your example with BUFFER
being 0 instead of nil, which is used in sendmail.el right now, and with
the small program returning non-0. There is no indication that something
went wrong. This probably solves the original problem.
11:32 a.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> However, the patch should still be applied, I think,
Simon> because otherwise you don't get any return value at all.
Simon> Try running your example with BUFFER being 0 instead of
Simon> nil, which is used in sendmail.el right now, and with the
Simon> small program returning non-0. There is no indication that
Simon> something went wrong.
Agreed.
Simon> This probably solves the original problem.
Highly unlikely. ;-) Gnus, as always, marches to the beat of a
different drummer. I think Kai's patch is necessary as well.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
11:37 a.m.
On 5 Jun 2002, Stephen J. Turnbull wrote:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> This probably solves the original problem.
Highly unlikely. ;-) Gnus, as always, marches to the beat of a
different drummer. I think Kai's patch is necessary as well.
Oops, I missed that one, I guess it wasn't CC'd to xemacs-beta or I did
something wrong when trying to find it (can't find it in this thread).
12:03 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
On 5 Jun 2002, Stephen J. Turnbull wrote:
> >>>>> "Simon" == Simon Josefsson <jas(a)extundo.com>
writes:
>
> Simon> This probably solves the original problem.
>
> Highly unlikely. ;-) Gnus, as always, marches to the beat of a
> different drummer. I think Kai's patch is necessary as well.
Oops, I missed that one, I guess it wasn't CC'd to xemacs-beta or I did
something wrong when trying to find it (can't find it in this thread).
I saw the message in ding.gnus-bug and posted there, I think. Sorry
about this.
(Hitting `F' in that group creates a posting to the group only. Maybe
I should get into the habit of using `S W' or `S V'... Or maybe I
don't grok nnimap-news-groups and use it wrongly.)
kai
--
Silence is foo!
12:17 p.m.
On Wed, 5 Jun 2002, Kai [iso-8859-15] Großjohann wrote:
Simon Josefsson <jas(a)extundo.com> writes:
> On 5 Jun 2002, Stephen J. Turnbull wrote:
>
>> >>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
>>
>> Simon> This probably solves the original problem.
>>
>> Highly unlikely. ;-) Gnus, as always, marches to the beat of a
>> different drummer. I think Kai's patch is necessary as well.
>
> Oops, I missed that one, I guess it wasn't CC'd to xemacs-beta or I did
> something wrong when trying to find it (can't find it in this thread).
I saw the message in ding.gnus-bug and posted there, I think. Sorry
about this.
I found the patch, but does it work? I think it needs the same patch as
sendmail.el as well, otherwise call-process-region will never return
anything useful. Of course, that message.el duplicates code from
sendmail.el so we need to fix both can probably be considered a bug in
itself. Sigh. I'll commit the same patch to sendmail.el in mail-lib and
Emacs.
--- message.el.~6.230.~ Wed Jun 5 12:06:29 2002
+++ message.el Wed Jun 5 13:11:40 2002
＠＠ -2968,7 +2968,7 ＠＠
(let ((errbuf (if message-interactive
(message-generate-new-buffer-clone-locals
" sendmail errors")
- 0))
+ nil))
resend-to-addresses delimline)
(let ((case-fold-search t))
(save-restriction
12:33 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
I found the patch, but does it work? I think it needs the same patch
as
sendmail.el as well, otherwise call-process-region will never return
anything useful. Of course, that message.el duplicates code from
sendmail.el so we need to fix both can probably be considered a bug in
itself. Sigh. I'll commit the same patch to sendmail.el in mail-lib and
Emacs.
--- message.el.~6.230.~ Wed Jun 5 12:06:29 2002
+++ message.el Wed Jun 5 13:11:40 2002
＠＠ -2968,7 +2968,7 ＠＠
(let ((errbuf (if message-interactive
(message-generate-new-buffer-clone-locals
" sendmail errors")
- 0))
+ nil))
resend-to-addresses delimline)
(let ((case-fold-search t))
(save-restriction
I also think this might be needed. But this kind of defeats the
variable message-interactive. With your change, setting the variable
to nil still means the user has to wait. Presumably, the idea behind
message-interactive was to make things faster?
Hm.
kai
--
Silence is foo!
5:01 p.m.
During this thread I've sort of lost touch with what patches are being
applied where. I'd like to test whatever the latest fixes are though.
--
(http://tmda.sourceforge.net/)
5:48 p.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
During this thread I've sort of lost touch with what patches are
being
applied where. I'd like to test whatever the latest fixes are though.
Kai applied the following to Oort Gnus. AFAIK nothing is committed to
XEmacs yet, but I may be wrong. Does this work? If not, does it work
when setting `message-interactive' to non-nil?
Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.228
retrieving revision 6.231
diff -u -p -u -w -r6.228 -r6.231
--- message.el 2002/04/21 02:42:45 6.228
+++ message.el 2002/06/05 11:51:09 6.231
＠＠ -2993,6 +2993,7 ＠＠ If you always want Gnus to send messages
(erase-buffer))))
(let ((default-directory "/")
(coding-system-for-write message-send-coding-system))
+ (let ((cpr
(apply 'call-process-region
(append (list (point-min) (point-max)
(if (boundp 'sendmail-program)
＠＠ -3015,7 +3016,9 ＠＠ If you always want Gnus to send messages
;; For a resend, include the specific addresses.
(if resend-to-addresses
(list resend-to-addresses)
- '("-t")))))
+ '("-t"))))))
+ (unless (or (null cpr) (zerop cpr))
+ (error "Sending...failed: %s" cpr))))
(when message-interactive
(save-excursion
(set-buffer errbuf)
8:12 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
Kai applied the following to Oort Gnus. AFAIK nothing is committed
to XEmacs yet, but I may be wrong. Does this work? If not, does it
work when setting `message-interactive' to non-nil?
Nope. After upgrading to the latest Oort from CVS, no change in
behavior. Even with (setq mail-interactive t) in my .emacs. Even
with your one-line sendmail.el patch applied.
--
(http://tmda.sourceforge.net/)
8:38 p.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
Simon Josefsson <jas(a)extundo.com> writes:
> Kai applied the following to Oort Gnus. AFAIK nothing is committed
> to XEmacs yet, but I may be wrong. Does this work? If not, does it
> work when setting `message-interactive' to non-nil?
Nope. After upgrading to the latest Oort from CVS, no change in
behavior. Even with (setq mail-interactive t) in my .emacs. Even
with your one-line sendmail.el patch applied.
Tres weird. Can you perhaps edebug message-send-mail-with-sendmail to
see what happens?
11:24 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
Tres weird.
Why, does it work for you?
Can you perhaps edebug message-send-mail-with-sendmail to see what
happens?
I did this, but I'm not sure what you are looking for.
I think you'll find this easier to debug yourself. It's pretty easy
to simulate.
In your .gnus:
(setq sendmail-program "/tmp/exit1")
/tmp/exit1:
#!/bin/sh
exit 1
--
(http://tmda.sourceforge.net/)
11:24 a.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
Simon Josefsson <jas(a)extundo.com> writes:
> Tres weird.
Why, does it work for you?
Yes.
> Can you perhaps edebug message-send-mail-with-sendmail to see
what
> happens?
I did this, but I'm not sure what you are looking for.
I think you'll find this easier to debug yourself. It's pretty easy
to simulate.
In your .gnus:
(setq sendmail-program "/tmp/exit1")
/tmp/exit1:
#!/bin/sh
exit 1
I get "Sending...failed: 1" in the minibuffer. I tried Kai's original
patch, and I tried the following (which I suggest is applied) against
the Gnus XEmacs package. Both worked as expected.
Index: message.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/gnus/lisp/message.el,v
retrieving revision 1.25
diff -u -p -u -w -r1.25 message.el
--- message.el 2001/02/08 08:57:19 1.25
+++ message.el 2002/06/06 10:22:45
＠＠ -236,7 +236,7 ＠＠ any confusion."
:type 'string
:group 'message-various)
-(defcustom message-interactive nil
+(defcustom message-interactive t
"Non-nil means when sending a message wait for and display errors.
nil means let mailer mail back a message to report errors."
:group 'message-sending
＠＠ -2388,6 +2388,7 ＠＠ It should typically alter the sending me
(erase-buffer))))
(let ((default-directory "/")
(coding-system-for-write message-send-coding-system))
+ (let ((cpr
(apply 'call-process-region
(append (list (point-min) (point-max)
(if (boundp 'sendmail-program)
＠＠ -2410,7 +2411,9 ＠＠ It should typically alter the sending me
;; For a resend, include the specific addresses.
(if resend-to-addresses
(list resend-to-addresses)
- '("-t")))))
+ '("-t"))))))
+ (unless (or (null cpr) (zerop cpr))
+ (error "Sending...failed with exit value %d" cpr))))
(when message-interactive
(save-excursion
(set-buffer errbuf)
5:19 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
I get "Sending...failed: 1" in the minibuffer. I tried
Kai's
original patch, and I tried the following (which I suggest is
applied) against the Gnus XEmacs package. Both worked as expected.
I'm not understanding the relationship between your patch and Kai's,
but they look pretty similar. I'm using latest CVS Oort, which
includes Kai's patch, and it didn't help this problem. Your patch
doesn't apply against latest CVS Oort.
--
(http://tmda.sourceforge.net/)
2:25 p.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
Simon Josefsson <jas(a)extundo.com> writes:
> Kai applied the following to Oort Gnus. AFAIK nothing is committed
> to XEmacs yet, but I may be wrong. Does this work? If not, does it
> work when setting `message-interactive' to non-nil?
Nope. After upgrading to the latest Oort from CVS, no change in
behavior. Even with (setq mail-interactive t) in my .emacs. Even
with your one-line sendmail.el patch applied.
I changed message.el, not sendmail.el.
kai
--
Silence is foo!
5:21 p.m.
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Nope. After upgrading to the latest Oort from CVS, no change in
> behavior. Even with (setq mail-interactive t) in my .emacs. Even
> with your one-line sendmail.el patch applied.
I changed message.el, not sendmail.el.
I was referring to Simon's sendmail.el patch here:
http://list-archive.xemacs.org/xemacs-beta/200206/msg00057.html
--
(http://tmda.sourceforge.net/)
7 p.m.
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> Nope. After upgrading to the latest Oort from CVS, no change in
>> behavior. Even with (setq mail-interactive t) in my .emacs. Even
>> with your one-line sendmail.el patch applied.
>
> I changed message.el, not sendmail.el.
I was referring to Simon's sendmail.el patch here:
http://list-archive.xemacs.org/xemacs-beta/200206/msg00057.html
Maybe so, but upgrading Gnus does not change sendmail.el, as
sendmail.el is not part of Gnus. And a change in sendmail.el will not
help Gnus, as Gnus uses message.el, instead.
So, did you upgrade sendmail.el, as well?
The Emacs 21.3 pretest appears to have a working sendmail.el; at least
it looks at the exit status of sendmail...
kai
--
~/.signature is: umop 3p!sdn (Frank Nobis)
7:31 p.m.
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
"Jason R. Mastaler" <jason(a)mastaler.com> writes:
> Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>>> Nope. After upgrading to the latest Oort from CVS, no change in
>>> behavior. Even with (setq mail-interactive t) in my .emacs. Even
>>> with your one-line sendmail.el patch applied.
>>
>> I changed message.el, not sendmail.el.
>
> I was referring to Simon's sendmail.el patch here:
>
> http://list-archive.xemacs.org/xemacs-beta/200206/msg00057.html
Maybe so, but upgrading Gnus does not change sendmail.el, as
sendmail.el is not part of Gnus. And a change in sendmail.el will not
help Gnus, as Gnus uses message.el, instead.
So, did you upgrade sendmail.el, as well?
The Emacs 21.3 pretest appears to have a working sendmail.el; at least
it looks at the exit status of sendmail...
But it isn't used by default, since mail-interactive defaults to nil.
I'll suggest it being changed.
11:18 p.m.
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
Maybe so, but upgrading Gnus does not change sendmail.el, as
sendmail.el is not part of Gnus. And a change in sendmail.el will
not help Gnus, as Gnus uses message.el, instead.
Understood.
So, did you upgrade sendmail.el, as well?
I'm running the sendmail.el which comes with XEmacs mail-lib v1.46,
with Simon's one-line patch applied.
The comments in my sendmail.el say:
;;; Synched up with: Emacs 21.0.106
--
(http://tmda.sourceforge.net/)
5:52 p.m.
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai Großjohann) writes:
Simon Josefsson <jas(a)extundo.com> writes:
> I found the patch, but does it work? I think it needs the same patch as
> sendmail.el as well, otherwise call-process-region will never return
> anything useful. Of course, that message.el duplicates code from
> sendmail.el so we need to fix both can probably be considered a bug in
> itself. Sigh. I'll commit the same patch to sendmail.el in mail-lib and
> Emacs.
>
> --- message.el.~6.230.~ Wed Jun 5 12:06:29 2002
> +++ message.el Wed Jun 5 13:11:40 2002
> ＠＠ -2968,7 +2968,7 ＠＠
> (let ((errbuf (if message-interactive
> (message-generate-new-buffer-clone-locals
> " sendmail errors")
> - 0))
> + nil))
> resend-to-addresses delimline)
> (let ((case-fold-search t))
> (save-restriction
I also think this might be needed. But this kind of defeats the
variable message-interactive. With your change, setting the variable
to nil still means the user has to wait. Presumably, the idea behind
message-interactive was to make things faster?
Oops. So this ignoring of errors are actually a feature. I think the
default of `message-interactive' should be non-nil, making Gnus wait
for errors.
The complete patch now is (against Oort Gnus). Does it work?
message.el in (X)Emacs need to be patched, as does sendmail.el in
(X)Emacs.
Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.228
diff -u -p -u -w -r6.228 message.el
--- message.el 2002/04/21 02:42:45 6.228
+++ message.el 2002/06/05 17:12:39
＠＠ -258,7 +258,7 ＠＠ any confusion."
:type 'string
:group 'message-various)
-(defcustom message-interactive nil
+(defcustom message-interactive t
"Non-nil means when sending a message wait for and display errors.
nil means let mailer mail back a message to report errors."
:group 'message-sending
＠＠ -2993,6 +2993,7 ＠＠ If you always want Gnus to send messages
(erase-buffer))))
(let ((default-directory "/")
(coding-system-for-write message-send-coding-system))
+ (let ((cpr
(apply 'call-process-region
(append (list (point-min) (point-max)
(if (boundp 'sendmail-program)
＠＠ -3015,7 +3016,9 ＠＠ If you always want Gnus to send messages
;; For a resend, include the specific addresses.
(if resend-to-addresses
(list resend-to-addresses)
- '("-t")))))
+ '("-t"))))))
+ (unless (or (null cpr) (zerop cpr))
+ (error "Sending...failed: %s" cpr))))
(when message-interactive
(save-excursion
(set-buffer errbuf)
5:07 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Jason's example is bogus here; the invocation of /tmp/emptyfile
succeeds! (At least on Linux, under ash, bash, and csh.)
Bogus? Emacs should silently succeed in this case? If for some
reason /usr/sbin/sendmail got truncated, you'd lose mail until you
happened to notice this.
Mutt for example bails out with:
"Error sending message, child exited 127 (exec error)"
Other MUAs behave in a similar fashion.
In any case, when I tested Simon's one-line patch, I was testing by
introducing a typo into my TMDA outgoing filter. Something also
caught by other MUAs. e.g, under Mutt:
"Error sending message, child exited 1 ()"
Traceback (most recent call last):
File "/home/jasonrm/cvs/tmda/dist/bin/tmda-inject", line 374, in ?
main()
File "/home/jasonrm/cvs/tmda/dist/bin/tmda-inject", line 340, in main
outfilter.read(Defaults.FILTER_OUTGOING)
File "/home/jasonrm/cvs/tmda/dist/TMDA/FilterParser.py", line 146, in read
self.__parse(fp)
File "/home/jasonrm/cvs/tmda/dist/TMDA/FilterParser.py", line 180, in __parse
raise exception
TMDA.FilterParser.ParsingError: Filter contains parsing errors:
/home/jasonrm/.tmda/filters/outgoing
[line 13]: "oops": unrecognized filter rule
--
(http://tmda.sourceforge.net/)
1:55 a.m.
>>>> "Jason" == Jason R Mastaler
<jason(a)mastaler.com> writes:
Jason> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Jason's example is bogus here; the invocation of
/tmp/emptyfile
> succeeds! (At least on Linux, under ash, bash, and csh.)
Jason> Bogus? Emacs should silently succeed in this case? If for
Jason> some reason /usr/sbin/sendmail got truncated, you'd lose
Jason> mail until you happened to notice this.
OK, you got me. Emacs should not silently succeed. ("In an ideal
world", but see Kyle's explanation of why sendmail-send-it has always
ignored sendmail return values.) But...
... the "easy test" (exec from the command line) succeeds in the sense
of returning 0.
What's going on here? Should we change call-process-*?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
11:16 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Jason" == Jason R Mastaler
<jason(a)mastaler.com> writes:
Jason> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>> Jason's example is bogus here; the invocation of /tmp/emptyfile
>> succeeds! (At least on Linux, under ash, bash, and csh.)
Jason> Bogus? Emacs should silently succeed in this case? If for
Jason> some reason /usr/sbin/sendmail got truncated, you'd lose
Jason> mail until you happened to notice this.
OK, you got me. Emacs should not silently succeed. ("In an ideal
world", but see Kyle's explanation of why sendmail-send-it has always
ignored sendmail return values.) But...
... the "easy test" (exec from the command line) succeeds in the sense
of returning 0.
What's going on here? Should we change call-process-*?
Try calling emptyfile using execle() in C, it fails. Calling it from
shells succeeds though. It seems like call-process-* somehow invokes
the shell and then the command (since it returns 0 when invoking an
empty file).
(call-process "/tmp/emptyfile") should not return 0 IMHO.
12:15 p.m.
I'm going to drop gnus-bugs since this is not a Gnus bug anymore. If
that's the wrong thing to do, feel free to repost -- but I think
they'd mostly prefer to pick up the thread again when we fix it ;-)
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> Try calling emptyfile using execle() in C, it fails.
Simon> Calling it from shells succeeds though. It seems like
Simon> call-process-* somehow invokes the shell and then the
Simon> command (since it returns 0 when invoking an empty file).
No, I checked that before sending my post. call-process does its
thing by forking and execvp(3), not through a system(3) call.
Simon> (call-process "/tmp/emptyfile") should not return 0 IMHO.
OK, but this is beyond me.
Ben, can you help? Please see the thread rooted at
http://list-archive.xemacs.org/xemacs-beta/200206/msg00054.html
for background.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:11 p.m.
On Thu, 06 Jun 2002 12:16:07 +0200, Simon Josefsson said:
Try calling emptyfile using execle() in C, it fails. Calling it
from
shells succeeds though. It seems like call-process-* somehow invokes
the shell and then the command (since it returns 0 when invoking an
empty file).
This is an artifact of how #! came to be, and how it works. A long time
ago, in a Unix version far away, there was only /bin/sh and exec*(). So if
you gave a command name, the shell would try to fork()/exec() it, and if it failed,
it would fork() and then try to read the file as a shell script. Then when
multiple shells came into existence, it got changed to "if it failed, it
would fork(), then run either ourselves or $SHELL to read it as input".
Then #! got added for flexibility and efficiency, as you could have it run
under a shell other than $SHELL and save a trip or two into the kernel
(which was REALLY important back on the 750/780 class systems).
And in fact, if $SHELL is set to something that signals an error on an
unexpected end-of-file, it might *NOT* return zero when invoking an
empty file....
(call-process "/tmp/emptyfile") should not return 0 IMHO.
Unfortunately, this has just too many subtle side effects - I've
seen systems where /bin/true and /bin/false rely on this sort of thing.
Yes, that's brain dead - /bin/true and /bin/false should be 'main()
{return(0)}'
type things (why they are 9144 bytes in size on RedHat 7.3 is code bloat
at its finest...)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
1:33 a.m.
sendmail-send-it runs sendmail-program with -oem which tells
sendmail to always exit with status 0 and report all errors via
e-mail. So sendmail-send-it is ignoring exit status because
there's no reason for it to expect exit status to be anything but
zero. If you change sendmail-program to something other than
sendmail then you take your chances with incompatible/broken
behavior.
3:57 a.m.
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
sendmail-send-it runs sendmail-program with -oem which tells
sendmail to always exit with status 0 and report all errors via
e-mail.
I think this applies to Allman Sendmail only. qmail for example
doesn't support this behavior.
So sendmail-send-it is ignoring exit status because there's no
reason for it to expect exit status to be anything but zero.
Then why don't Pine, Mutt and mailx also ignore the exit status?
If you change sendmail-program to something other than sendmail then
you take your chances with incompatible/broken behavior.
"incompatible/broken behavior" is obviously subjective. Unless this
bug is fixed however, Emacs users will continue to mysteriously and
unnecessarily lose mail.
--
(http://tmda.sourceforge.net/)
11:27 a.m.
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
sendmail-send-it runs sendmail-program with -oem which tells
sendmail to always exit with status 0 and report all errors via
e-mail. So sendmail-send-it is ignoring exit status because
there's no reason for it to expect exit status to be anything but
zero. If you change sendmail-program to something other than
sendmail then you take your chances with incompatible/broken
behavior.
IMHO losing mail is such an unpleasant thing that a little extra error
checking is worth it. Even though -oem is used, it makes sense the
check error codes because 1) it catches installation problems and 2)
might catch severe sendmail problems (what if if sendmail cannot send
mail to report the error? What does it do? Probably return with an
error code anyway). If sendmail clones doesn't implement -oem it is
another argument.
3:17 p.m.
On Thu, 06 Jun 2002 12:27:47 +0200, Simon Josefsson said:
IMHO losing mail is such an unpleasant thing that a little extra
error
checking is worth it. Even though -oem is used, it makes sense the
In fact, this logic was exactly why Sendmail 8.12's design for removing
the set-UID bit is so byzantine (basically, it kept the set-GID bit
and a separate group-writable spool directory just in case it couldn't write
into the main mqueue directory). Eric Allman put his foot down and said
that we were *not* allowed to lose mail, no matter how unlikely. If we'd been
able to drop stuff on the floor, the design would have been a lot simpler.
/Valdis (who was there)
8205
days inactive
8207
days old
32 comments
6 participants
participants (6)
-
Jason R. Mastaler -
Kai Großjohann -
Kyle Jones -
Simon Josefsson -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks