[Top][All Lists]

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

call-process temp buffer modified when it shouldn't be

From: Paul Smith
Subject: call-process temp buffer modified when it shouldn't be
Date: Fri, 07 Dec 2001 16:49:53 -0500

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2001-12-04 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr 
--sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib 
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes 
--with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: 
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

My mail was not being retrieved properly by Gnus nnfolder.  After a lot
of hacking around, I discovered that it was because when Gnus invoked
movemail it ran the following code (gnus/mail-source.el:mail-source-movemail):

              (let ((default-directory "/"))
                (setq result
                         (expand-file-name "movemail" exec-directory)
                         nil errors nil from to)))))
              (when (file-exists-p to)
                (set-file-modes to mail-source-default-file-modes))
              (if (and (not (buffer-modified-p errors))
                       (zerop result))
                  ;; No output => movemail won.

IOW, after the call-process for movemail it tested two things, the exit
code and the modification status of the buffer.  Movemail succeeded and
did the right thing, so the return code was 0.  However, the buffer was
marked as modified!  I looked and it was completely empty (as expected).

So then I played around with "emacs -q -no-site-file" and I discovered
that if I had these two customizations set up (and nothing else) in

   '(inhibit-eol-conversion t)
   '(enable-multibyte-characters nil)

then the problem would show up.  If I allowed either of these two
variables to remain at their default value, then the problem would not

I created a test like this:

  $ cd /tmp
  $ mkdir foo
  $ echo hi > foo/x

Then I eval'd the above custom-set-variables sexp and then these, in
order, to emulate what Gnus does:

  (setq from "/tmp/foo/x" to "/tmp/foo/y")
  (setq errors (generate-new-buffer " *my mail source loss*"))
  (apply 'call-process (append (list (expand-file-name "movemail"
                                     nil errors nil from to)))
  (buffer-modified-p errors)

The last line, buffer-modified-p, should return nil since the buffer
should not be modified by a successful movemail invocation.  However, it
will be t instead.

If you re-run the test but this time comment out either or both of the
custom variable settings, you'll get nil from buffer-modified-p just as
you'd expect.

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 

Recent messages:
Loading /usr/share/emacs/21.1/lisp/emacs-lisp/regexp-opt.elc...done
Loading /opt/home/psmith/.custom...done
Loading /usr/share/emacs/21.1/lisp/textmodes/flyspell.elc...done
(Next local Ispell command will use american dictionary) [2 times]
Starting new Ispell process...
Loading /usr/share/emacs/21.1/lisp/imenu.elc...done
For information about the GNU Project and its goals, type C-h C-p.
Loading /usr/share/emacs/21.1/lisp/lazy-lock.elc...done
Gnuserv process exited; restart with `M-x gnuserv-start'
Loading /usr/share/emacs/21.1/lisp/mail/emacsbug.elc...done

 Paul D. Smith <address@hidden> HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
   These are my opinions---Nortel Networks takes no responsibility for them.

reply via email to

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