emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Gnus and Emacs: Several Questions


From: Herbert Euler
Subject: Gnus and Emacs: Several Questions
Date: Thu, 21 Jun 2007 17:13:32 +0800

Recently I started to try Gnus.  Because both the mail servers in my
workplace and on Google require secure connection, I tried the one in
the Gnus trunk instead of the one comes with Emacs.

I run Emacs (and so Gnus) on two platforms: FreeBSD and Windows.  With
a lot of effort I can run Gnus on FreeBSD successfully now, but I
still have troubles with Gnus on Windows.  I looked at the whole
process during a Gnus session, and found some strange behaviors that I
do not understand.  In this message I will post them.  Please take a
look at them and see whether they are expected.  Thanks.

Gnus opens secure connection with external programs, defaults are
`gnutls-cli' or `openssl'.  `gnutls-cli' takes precedence over
`openssl': if `gnutls-cli' is avaliable on a system, `openssl' will
not be tried unless `gnutls-cli' fails.  Gnus uses `start-process' to
create asynchoronous (sub)processes to invoke the external programs
and uses `accept-process-output' to read the external program output.

This first strange behavior I found is on the output read by Emacs.  I
add some code around the place invoking `accept-process-output' in
pop3.el in Gnus, as below:

   ;; Borrowed from nnheader-accept-process-output in nnheader.el.
   (defun pop3-accept-process-output (process)
     (with-temp-buffer
       (insert "In `pop3-accept-process-output':\n")
       (insert (format "  pop3-read-point: %d\n" pop3-read-point))
       (insert ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\n")
       (insert-buffer (process-buffer process))
       (goto-char (point-max))
       (insert "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\n")
       (let ((r (accept-process-output
                 process
                 (truncate pop3-read-timeout)
                 (truncate (* (- pop3-read-timeout
                                 (truncate pop3-read-timeout))
                              1000)))))
         (insert (format "  `accept-process-output' returns %s\n" r)))
       (insert (format "  pop3-read-point: %d\n" pop3-read-point))
       (insert ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\n")
       (insert-buffer (process-buffer process))
       (goto-char (point-max))
       (insert "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\n\n")
       (append-to-file (point-min) (point-max) "d:/debug-emacs.txt")))

Now the process buffer content both before and after invoking
`accept-process-output' can be dumped into a file.  Note that the file
name above is a Windows-style name, but on the FreeBSD system I
substitute it with a UNIX-style name.  There is two newlines at the
end of the temporary buffer, so the dumped file is composed of many
"blocks" separated with a newline character, each of the blocks
started with the sentence "In `pop3-accept-process-output':".

On the FreeBSD system I have `openssl' but `gnutls-cli'.  The attached
file "bsd-debug-emacs-openssl" shows the typical output by executing
"openssl s_client -connect server.com:port -no_ssl2", which is the
same command with the same arguments as Gnus.  Some of the output is
printed to standard output by `openssl', other is to standard error.
The attached file "bsd-debug-emacs" shows the process buffer content.

In the second block of the process buffer, Gnus deletes many
uninteresting lines.  But the first block shows that the output read
by Emacs is not the same as that printed by `openssl'.  IIRC, when
Emacs creates subprocesses, the error stream and the output stream are
combined together for the subprocesses.  So IMO the output read by
Emacs should be exactly the same as the subprocess output.  But the
two files contradict to this assumption.  In practice I find that the
order of the output read by Emacs is possibly not the same as I can
see on terminal: output from standard error may comes before output
from standard output.  But I can explain this with "standard output is
usually buffered while standard error is not".

Is the above behavior expected?

Situation on the Windows system is rather strange: I may have to
"sit-for" some seconds in order to get the process output.
`gnutls-cli' is used on Windows, so the dumped file shows the output
by `gnutls-cli'.

If the definition of `pop3-accept-process-output' is as above, I get
the attached dumped file "w32-debug-emacs.txt".  There are two blocks
in that file, and four instances of the process buffer content, but
only the last instance has a "+OK" line.  This line is output by
`gnutls-cli' only when it finishes connecting, and Gnus waits for this
line.  If `gnutls-cli' is executed from command line, the line is
outputed very quickly.  But if `gnutls-cli' is executed in Emacs, the
line is not read for long, and Emacs hangs.  When I type C-g, Emacs
stops hanging and read the line.  This is why there is a "+OK" line
there.

However, if I add "(sit-for 3)" before invoking
`accept-process-output' in the above `pop3-accept-process-output'
function, the "+OK" line is read quickly (although not as quickly as
in command line).  The attached file "w32-debug-emacs-sit-for.txt"
shows the situation: in the first block includes a line that contains
"+OK", and so Gnus continues to send POP commands.

Problem remains when Gnus sends the "RETR" command.  There's nothing
read by Emacs, similar to the above situation when logging in on
Windows.  Again, after waiting for long I press C-g to quit, and the
output is read by Emacs.  The last several block in the file
"w32-debug-emacs-sit-for.txt" shows what happens.  But because I quit
from this process, I cannot receive messages with Gnus.

Is this behavior expected?  It seems `accept-process-output' on
Windows is broken.

And finally, I find on FreeBSD the POP command "RETR 1" does not
work.  Instead of retrieving the message, it prints

RENEGOTIATING
depth=0 /C=CN/O=ssl.alibaba-inc.com/OU=businessprofile.geotrust.com/get.jsp?GT81073306/OU=See www.geotrust.com/resources/cps (c)06/OU=Domain Control Validated - QuickSSL Premium(R)/CN=ssl.alibaba-inc.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CN/O=ssl.alibaba-inc.com/OU=businessprofile.geotrust.com/get.jsp?GT81073306/OU=See www.geotrust.com/resources/cps (c)06/OU=Domain Control Validated - QuickSSL Premium(R)/CN=ssl.alibaba-inc.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CN/O=ssl.alibaba-inc.com/OU=businessprofile.geotrust.com/get.jsp?GT81073306/OU=See www.geotrust.com/resources/cps (c)06/OU=Domain Control Validated - QuickSSL Premium(R)/CN=ssl.alibaba-inc.com
verify error:num=21:unable to verify the first certificate
verify return:1

But "retr 1" receives the message.  Is this expected?

Sorry for the long post.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Attachment: bsd-debug-emacs
Description: Binary data

Attachment: bsd-debug-emacs-openssl
Description: Binary data

Attachment: w32-debug-emacs.txt
Description: Text document

Attachment: w32-debug-emacs-with-sit-for.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]