Kevin Rodgers <[EMAIL PROTECTED]> writes:
> I came across a similar problem in one of my own packages that uses
> call-process to determine what options an external program supports.
>
> It's easy to fix by checking first that executable-find returns non-nil,
> or by wrapping call-process in condition-case.
>
> But that wasn't necessary before, so I suspect that call-process has
> changed to now signal an error.
Unless there's a really compelling reason for this change I think it
should be reverted. A *lot* of code depends on the assumption that
`call-process' returns a non-zero value if it fails.
Hmm, some years ago I fixed some calls that incorrectly assumed a
numerical return value, so these are just a few of the places that
will probably fail to work correctly if it signals an error instead:
2004-01-03 Jesper Harder <[EMAIL PROTECTED]> (tiny change)
* progmodes/idlwave.el (idlwave-make-tags):
* textmodes/flyspell.el (flyspell-large-region):.
* progmodes/make-mode.el (makefile-query-by-make-minus-q):
* emulation/viper-util.el (viper-glob-unix-files):
* emacs-lisp/shadow.el (shadow-same-file-or-nonexistent):
* man.el (Man-init-defvars):
* jka-compr.el (jka-compr-call-process):
* files.el (get-free-disk-space,insert-directory):
* ediff-ptch.el (ediff-test-patch-utility):
* ediff-diff.el (ediff-test-utility):
* dired-aux.el (dired-check-process):
* mail/sendmail.el (sendmail-send-it): Don't use = or zerop to
test the return value of call-process, because it can be a string.
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
