[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[h-e-w] call-process (and movemail)
From: |
David J. Biesack |
Subject: |
[h-e-w] call-process (and movemail) |
Date: |
Tue, 12 Feb 2002 09:43:59 -0500 (EST) |
Running: GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381) of 2001-10-22 on buffy
I'm having a problem with RMAIL/movemail. rmail.el calls movemail thusly:
(apply 'call-process args)
(if (not (buffer-modified-p errors)
;; No output => movemail won
nil
When I run rmail, movemail works as expected - it moves my mail.
Unfortunately, it also marks the " *rmail loss*" buffer as modified,
even though there is no output, and rmail.el thinks movemail failed.
I simplified the problem down to the following. If I run emacs -q and
eval the following in *scratch*:
(progn
(setq errors (generate-new-buffer "*process*"))
(setq explicit-shell-file-name "bash")
(setenv "SHELL" "bash")
(setenv "ESHELL" "bash")
(call-process "true" nil errors nil)
(switch-to-buffer-other-window errors))
then the *process* buffer is not marked as modified. ('true' here is
cygwin's true(1) which simply returns a 0 return code.) This is the
expected/correct case.
If emacs loads my .emacs and I evaluate this, the *process* buffer IS
modified. Unfortunately, I have *tons* of emacs lisp that I load, and
since call-process is a subr I can't determine what accounts for this
difference. I'm using cygwin bash, so the above explicitly sets that,
but that does not account for change in behavior. I also disabled all
advice to no avail.
Anyone know what could cause call-process to modify the buffer even when
there is no output?
The only fix I know is to patch rmail.el to check
(apply 'call-process args))
(if (or (not (buffer-modified-p errors))
(zerop (buffer-size errors)))
;; No output => movemail won
nil
thanks
--
David J. Biesack SAS Institute Inc.
R&D Java Strategist SAS Campus Drive Cary, NC 27513
(919) 531-7771 http://www.sas.com
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [h-e-w] call-process (and movemail),
David J. Biesack <=