(load "file" 'noerror) could be more robust

(load "file" 'noerror) could be more robust

[Matthew Swift]

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 bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-11-06 on beth, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr/local --sharedstatedir=/var/lib --libexecdir=/usr/local/lib --localstatedir=/var/lib --infodir=/usr/local/share/info --mandir=/usr/local/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: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

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


It seems to me that it would be useful for the NOERROR flag (or an
analogous flag) to the builtin function `load' to cause `load' to
refrain from signalling an error when a nonexistent environment
variable is part of the filename.

Conceptually, it seems to me that most often the relevant question is
simply whether a given string resolves to an existing file or not, and
that one typically does not care which of several possible causes led
to the failure to resolve.

There are several reasonable ways to provide this functionality.

One can check in Lisp explicitly with `getenv' before using `load'.
This is verbose, and only works when the programmer knows the string
to be passed to `load'.

One can wrap `load' in Lisp in a `condition-case', but this is
verbose, and there is no special error-condition that identifies the
case of a nonexistent environment variable, so that the only way to
avoid suppressing other kinds of error as well would be a kludgy check
for the exact message string that the error produces.  An
error-condition could be assigned with a small modification, but the
Lisp construction still remains verbose, e.g. if one assigned
`badvar':

    (condition-case err
      (load "$UNKNOWN/xxx" t)
      (badvar nil))

When bash encounters a nonexistent variable, it (by default) silently
substitutes the empty string.  The behavior of signalling an error,
instead, can be selected with "set -u".  A parallel global variable
could be introduced in Emacs.  This would be a good choice if there
are situations other than `load' where this control would be useful.

Substituting an empty string may lead to unexpected results and
present a security or at least an accident risk, however, so a
preferable third choice in the context of `load' would be neither to
signal an error nor to substitute the empty string, but simply to
return nil, so that strings containing a nonexistent environment
variable never resolve to an existing filename.  If it were useful to
provide all three choices, the global variable could be three-valued.

A 'badvar-OK flag could be added to the optional arguments of `load',
with meanings just like the proposed global variable.

Or the interpretation of the existing 'noerror flag could be modified
to include the case of nonexistent environment variables, in one of
the two alternative ways described.

None of these possibilities would be hard to implement, but it is hard
to decide which one, if any, is wise to choose.  I am submitting this
idea for consideration, not making an unreserved case for it.  I think
such a modification would present no compatibility problem because
prior code that did not signal errors before would remain valid.  Some
code that previously signalled errors would become valid, but it seems
unlikely that anyone would write code that relies on such an error
being caught.

Here is a brief demonstration of current behavior, for reference:

    (getenv "HOME")
    "/home/swift"

    (getenv "HOMEY")
    nil

    (file-exists-p (substitute-in-file-name "$HOME/bunny"))
    nil

    (load "$HOME/bunny" t)
    nil

    (load "$HOMEY/bunny" t)

    Debugger entered--Lisp error: (error "Substituting nonexistent environment variable \"HOMEY\"")
      load("$HOMEY/bunny" t)
      eval((load "$HOMEY/bunny" t))
      eval-last-sexp-1(t)
      eval-last-sexp(t)
      eval-print-last-sexp()
      call-interactively(eval-print-last-sexp)







Recent input:
c e l l a n e o u s SPC M-q C-a C-n C-e SPC SPC <return> 
<return> M u c h SPC l o v e , <return> M a t t C-x 
C-s C-c C-g C-c C-g C-a C-p C-o T h a n k s SPC a g 
a i n , SPC a n d C-a C-n C-o C-p M-l C-a C-n C-x C-s 
C-c C-c C-p q s g g <up> <up> <up> <up> <up> <up> M-x 
r e p o r t - e m a c s - b u g <return>

Recent messages:
1 <- require: nnmail
======================================================================
1 -> require: feature=nnmail filename=nil noerror=nil
1 <- require: nnmail
Checking new news...done
Loading emacsbug...
======================================================================
1 -> require: feature=sendmail filename=nil noerror=nil
1 <- require: sendmail
Loading emacsbug...done

Re: (load "file" 'noerror) could be more robust

[Richard Stallman]

    It seems to me that it would be useful for the NOERROR flag (or an
    analogous flag) to the builtin function `load' to cause `load' to
    refrain from signalling an error when a nonexistent environment
    variable is part of the filename.

Does this do the job?

*** lread.c.~1.303.~	Sat Dec  7 07:25:43 2002
--- lread.c	Sun Dec 15 14:36:51 2002
***************
*** 637,642 ****
--- 637,650 ----
    return Vloads_in_progress = old;
  }
  
+ /* This handler function is used via internal_condition_case_1.  */
+ 
+ static Lisp_Object
+ load_error_handler (data)
+      Lisp_Object data;
+ {
+   return Qnil;
+ }
  
  DEFUN ("load", Fload, Sload, 1, 5, 0,
         doc: /* Execute a file of Lisp code named FILE.
***************
*** 692,698 ****
       everywhere, it accidentally stayed here.  Since then, enough people
       supposedly have things like (load "$PROJECT/foo.el") in their .emacs
       that it seemed risky to remove.  */
!   file = Fsubstitute_in_file_name (file);
  
    /* Avoid weird lossage with null string as arg,
       since it would try to load a directory as a Lisp file */
--- 700,715 ----
       everywhere, it accidentally stayed here.  Since then, enough people
       supposedly have things like (load "$PROJECT/foo.el") in their .emacs
       that it seemed risky to remove.  */
!   if (! NILP (noerror))
!     {
!       file = internal_condition_case_1 (Fsubstitute_in_file_name, file,
! 					Qt, load_error_handler);
!       if (NILP (file))
! 	return Qnil;
!     }
!   else
!     file = Fsubstitute_in_file_name (file);
!     
  
    /* Avoid weird lossage with null string as arg,
       since it would try to load a directory as a Lisp file */
***************
*** 731,739 ****
    if (fd == -1)
      {
        if (NILP (noerror))
! 	while (1)
! 	  Fsignal (Qfile_error, Fcons (build_string ("Cannot open load file"),
! 				       Fcons (file, Qnil)));
        else
  	return Qnil;
      }
--- 748,755 ----
    if (fd == -1)
      {
        if (NILP (noerror))
! 	Fsignal (Qfile_error, Fcons (build_string ("Cannot open load file"),
! 				     Fcons (file, Qnil)));
        else
  	return Qnil;
      }