Mailing List Archive

On Wed, 18 Oct 2006, John Jetmore wrote:

> -bf looks interesting, but I'm not really sure what you'd feed it.

What I means was that you could write your test expansion as a filter
file, e.g.

# Exim filter
testprint "$interface \n $h_received:"

and then test it with exim -bf and a test message.

> One thing that might be interesting would be to have an option where
> you could feed it a test message as normal (say w/ -bh), but after
> processing it drops into -be mode. But I think that's over my head
> for implementing right now.

The -bf method is sort of like that, but less interactive. A kind of
amalgamation (-bef?) might be possible.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On Thu, 19 Oct 2006, John Jetmore wrote:

> Attached patch replces previous patch. It doesn't address any of the
> other interesting stuff we've talked about but it at least is a correct
> implementation of what I originally intended to create. Specifically I
> was missing $message_body_size, $message_size, $message_id, and
> $message_exim_id.

I have applied and slightly modified this patch. It also turns out that
with only a very small number of added code lines I was able to
implement an option that reads a message from an ordinary file (sort of
like a command-line submission) and then does the -be thing. For this
you do not have to be an admin user. That code is now also committed, so
both will be in tonight's snapshot.

Philip

--
Philip Hazel, University of Cambridge Computing Service.

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On Tue, 24 Oct 2006, John Jetmore wrote:

> On Tue, 24 Oct 2006, Philip Hazel wrote:
>
> > I have applied and slightly modified this patch. It also turns out that
> > with only a very small number of added code lines I was able to
> > implement an option that reads a message from an ordinary file (sort of
>
> I was playing with this and I ran into an issue that I don't fully
> understand and which appears to be Mac OS X specific.

Many thanks for playing! This might well have gone unnoticed for a long
time otherwise.

> (void)dup2(save_stdin, 0);
> (void)close(save_stdin);
> +if (feof(stdin)) {
> + fprintf(stderr, "stdin _is_ at eof()\n");
> + clearerr(stdin);
> +} else {
> + fprintf(stderr, "stdin is _not_ at eof()\n");
> +}

Looks me as if the dup'ing and then closing the 'other' fd is having the
(to me, unexpected) effect of marking the copied fd as "at eof".
However, I too am no expert at this level of system call. I do know,
however, that on systems I've used (Solaris, Linux), you can usually
read "beyond" eof on terminal input without using clearerr(). That is,
you can type ^D and the program will see "eof", but if it reads again
you can type more. My guess is that this is different on Darwin. I
predict you'll need clearerr(). And of course, we are also dealing with
the interaction of the system with the C input/output library.

It seems to me that there's no harm in calling clearerr()
unconditionally. On the other hand, re-reading the man page for "dup",
it may be that I shouldn't have used "close" there. Please can you test
by removing that "close" call?

Philip

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On 10/25/06 7:53 AM, "John Jetmore" <jetmore@cinergycom.com> wrote:

> On Wed, 25 Oct 2006, Philip Hazel wrote:
>
>> Looks me as if the dup'ing and then closing the 'other' fd is having the
>> (to me, unexpected) effect of marking the copied fd as "at eof".
>
> What's wierd is that stdin is being marked as "at eof" on Linux and
> Solaris also. It's just that subsequent reads still succeed.
>
>> However, I too am no expert at this level of system call. I do know,
>> however, that on systems I've used (Solaris, Linux), you can usually
>> read "beyond" eof on terminal input without using clearerr(). That is,
>> you can type ^D and the program will see "eof", but if it reads again
>> you can type more. My guess is that this is different on Darwin. I
>
> The read that's actually behaving differently in Darwin is the fgets() in
> exim.c:get_stdinput(). The man pages on Darwin and Linux appear identical
> for fgets(). HOWEVER, I was just looking at the man pages on both systems
> for getc(), which is the call in filtertest.c:read_message_body() that's
> actually setting EOF on stdin. Check this out:
>
> Darwin:
> RETURN VALUES
> <snip>
> global variable errno is set to indicate the error. The end-of-file con-
> dition is remembered, even on a terminal, and all subsequent attempts to
> read will return EOF until the condition is cleared with clearerr(3).
>
> So it looks like Darwin's libs just don't behave the same way. I played
> around with variations of the attached code and it really does seem to be
> that Darwin sets eof on a stream permanently (until clearerr() at least)
> and other systems clear eof themselves on subsequent reads.
>
>> It seems to me that there's no harm in calling clearerr()
>> unconditionally. On the other hand, re-reading the man page for "dup",
>> it may be that I shouldn't have used "close" there. Please can you test
>> by removing that "close" call?
>
> I did test, the close doesn't matter. It seems like an unconditional
> clearerr(stdin) will fix the problem on Darwin (and possibly other
> systems) and do not harm on other systems.

The proposed fix feels right (whether installed conditionally or not as
seems best).

Mac OS X is different in that, instead of terminal programs pretending to be
terminals--which could also be attached the old fashioned way--Mac OS X
knows there won't be terminals attached, but only terminal programs.

It might be interesting--and necessary if the change is unconditional--to
get this tested on Exim under Cygwin (sorry, I don't think I'll install
Cygwin on my XP, which runs under the Parallels virtual machine, to find
out).

--John



--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##