Mercurial > emacs
view admin/notes/exit-value @ 74984:21f28d10d73a
Merge from gnus--rel--5.10
Patches applied:
* gnus--rel--5.10 (patch 179-183)
- Update from CVS
2006-12-25 Daiki Ueno <ueno@unixuser.org>
* lisp/pgg-def.el (pgg-passphrase-coding-system): Default to nil instead of
locale-coding-system.
* lisp/pgg-gpg.el (pgg-gpg-process-region): Encode passphrase with eol-type
LF.
2006-12-29 Jouni K. Sepp,Ad(Bnen <jks@iki.fi>
* lisp/gnus/nnimap.el (nnimap-expunge-search-string): Mention
nnimap-search-uids-not-since-is-evil in docstring.
2006-12-28 Reiner Steib <Reiner.Steib@gmx.de>
* lisp/gnus/spam.el: Revert to make-obsolete-variable because
define-obsolete-variable-alias is not supported in Emacs 21.
2006-12-28 Daiki Ueno <ueno@unixuser.org>
* lisp/gnus/gnus-sum.el (gnus-summary-next-article): Make sure we are in the
summary buffer.
2006-12-27 Reiner Steib <Reiner.Steib@gmx.de>
* lisp/gnus/spam.el (spam-ifile-path, spam-ifile-database-path)
(spam-bogofilter-path): Use define-obsolete-variable-alias instead of
make-obsolete-variable.
2006-12-26 Reiner Steib <Reiner.Steib@gmx.de>
* lisp/gnus/message.el (message-make-fqdn): Fix comment.
(message-bogus-system-names): Add ".local".
* lisp/gnus/spam.el (spam-ifile-path, spam-ifile-program)
(spam-ifile-database-path, spam-ifile-database)
(spam-bogofilter-path, spam-bogofilter-program): Rename variables.
Don't use "path" inappropriately.
(spam-spamoracle-database, spam-get-ifile-database-parameter): Fix doc
strings.
(spam-check-ifile, spam-ifile-register-with-ifile)
(spam-check-bogofilter, spam-bogofilter-register-with-bogofilter): Use
new variable names.
* lisp/gnus/gnus-art.el (gnus-treat-display-x-face, gnus-treat-display-face)
(gnus-treat-display-smileys): Simplify using
gnus-image-type-available-p.
* lisp/gnus/gnus-ems.el (gnus-image-type-available-p): Use display-images-p if
available.
2006-12-22 Katsumi Yamaoka <yamaoka@jpl.org>
* lisp/gnus/nnrss.el (nnrss-fetch): Replace buffer's contents with the decoded
one after turning on the buffer's multibyteness instead of decoding
them directly in the unibyte buffer that causes unexpected conversion
in Emacs 23 (unicode).
2006-12-29 Reiner Steib <Reiner.Steib@gmx.de>
* man/gnus.texi (Customizing Articles): Add index entries for all
gnus-treat-* variables.
2006-12-29 Jouni K. Sepp,Ad(Bnen <jks@iki.fi>
* man/gnus.texi (IMAP): Fix incorrect explanation of
nnimap-search-uids-not-since-is-evil in documentation for
nnimap-expunge-search-string.
2006-12-27 Reiner Steib <Reiner.Steib@gmx.de>
* man/gnus.texi (ifile spam filtering): Rename spam-ifile-database-path to
spam-ifile-database.
2006-12-26 Reiner Steib <Reiner.Steib@gmx.de>
* man/gnus.texi (Spam Package Configuration Examples): Don't encourage to
rebind C-s.
2006-12-26 Jouni K. Sepp,Ad(Bnen <jks@iki.fi>
* man/gnus.texi (Group Parameters, Group Maintenance, Topic Commands)
(Mail Group Commands, Expiring Mail, IMAP): Add index entries for
"expiring mail".
(IMAP): Document nnimap-search-uids-not-since-is-evil and
nnimap-nov-is-evil.
Revision: emacs@sv.gnu.org/emacs--devo--0--patch-576
author | Miles Bader <miles@gnu.org> |
---|---|
date | Sat, 30 Dec 2006 15:34:42 +0000 |
parents | dc9bd6dd0d8d |
children |
line wrap: on
line source
ttn 2004-05-09 The exit value of a program returning to the shell on unixoid systems is typically 0 for success, and non-0 (such as 1) for failure. For vms it is odd (1,3,5...) for success, even (0,2,4...) for failure. This holds from the point of view of the "shell" (in quotes because vms has a different dispatch model that is not explained further here). From the point of view of the program, nowadays stdlib.h on both type of systems provides macros `EXIT_SUCCESS' and `EXIT_FAILURE' that should DTRT. NB: The numerical values of these macros DO NOT need to fulfill the the exit value requirements outlined in the first paragraph! That is the job of the `exit' function. Thus, this kind of construct shows misunderstanding: #ifdef VMS exit (1); #else exit (0); #endif Values aside from EXIT_SUCCESS and EXIT_FAILURE are tricky. ttn 2004-05-12 Values aside from EXIT_SUCCESS and EXIT_FAILURE can be used to indicate finer gradations of failure. If this is the only information available to the caller, clamping such values to EXIT_FAILURE loses information. If there are other ways to indicate the problem to the caller (such as a message to stderr) it may be ok to clamp. In all cases, it is the relationship between the program and its caller that must be examined. [Insert ZAMM quote here.]