mirror of
git://git.sv.gnu.org/emacs.git
synced 2025-12-26 07:11:34 -08:00
6d9d9cde2f
* notes/exit-value: Remove specific discussion of VMS. * doc/emacs/programs.texi (Program Modes): Don't advertise VMS DCL support any more. * doc/misc/ediff.texi (Merging and diff3): Don't mention lack of support for VMS diff, we no longer support VMS. * lisp/progmodes/ada-mode.el: * lisp/net/tramp.el (tramp-handle-file-symlink-p): * lisp/net/tramp-ftp.el (tramp-ftp-file-name-handler): Remove a comment about VMS, which we no longer support. * lisp/progmodes/ada-xref.el (ada-xref-current): Remove mention of VMS, and fix a FIXME, using convert-standard-filename in place of removed ada-convert-file-name. * lisp/url/url-handlers.el: Remove a comment about VMS, which we no longer support.
28 lines
1.2 KiB
Text
28 lines
1.2 KiB
Text
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. This is
|
|
not always the case on other systems.
|
|
|
|
From the point of view of the program stdlib.h provides macros
|
|
`EXIT_SUCCESS' and `EXIT_FAILURE' that should DTRT. N.B. The
|
|
numerical values of these macros DO NOT need to fulfill 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 WEIRD_OS
|
|
exit (1);
|
|
#else
|
|
exit (0);
|
|
#endif
|
|
|
|
Values aside from EXIT_SUCCESS and EXIT_FAILURE are tricky, but 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.] <-- I presume this refers to ``Zen and the
|
|
Art of Motorcycle Maintenance'' - Reuben Thomas <rrt@sc3d.org>.
|