|
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 RENEGOTIATINGdepth=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:1depth=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:1depth=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/
bsd-debug-emacs
Description: Binary data
bsd-debug-emacs-openssl
Description: Binary data
w32-debug-emacs.txt
Description: Text document
w32-debug-emacs-with-sit-for.txt
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |