help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: test for presence of library


From: Pascal J. Bourguignon
Subject: Re: test for presence of library
Date: Sat, 20 Feb 2010 10:54:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (darwin)

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>  Harry wrote:
>>> The lisp equivalent of:
>>>
>>>  if some-lib 
>>>  then
>>>     (require some-lib)
>>>  fi
>>
>>
>> require does the test itself!
>>
>> C-h f require RET
>>
>>
>> Now, assume that we wrote:
>>
>> (when (library-exists-p 'some-lib)
>>    (require 'some-lib))
>>
>> and that just after your emacs executed (library-exists-p 'some-lib)
>> and returned true, some other process would delete that some-lib.el
>> file.  What would happen to your (require 'some-lib)?
>>
>>
>> That is, basically, your above shell script with if [ -f /my/file ] is
>> just WRONG!  If you see such tests in scripts, you are allowed to think
>> poorly of their authors.
>
> Don't hold back, in this case you are allowed and really forced to
> think poorly of the author who admits to having literally hundreds of
> such tests scattered thru a 10yr accumulation of various scripts in
> various scripting languages. 

Don't worry, you're better than your self from the past.  We all have
old code that would need big "refactoring"...


> I start emacs with `emacs /some/path/file'.... but whoops, since
> `some-lib' is not in the path in this environment... my emacs blows up
> a bit.  It throws up a confusing buffer full of various leads to
> information, but none of it appears to bear directly on the job at
> hand. .. Not even any indication of what the problem is.


This "blowing up" is the generation and handling of an error.  This
buffer is a backtrace that shows the stack of functions called to reach
the point where the error has been detected.


As an error, it could be dealt generally using operators such as
ignore-errors or condition-case.  But in the case of require, there's
another option.

> But looking at the suggested documentation I'm left non the wiser:
>
>  (require FEATURE &optional FILENAME NOERROR)
>
> That isn't going to get it for me.. I've tried a few arrangements but
> being an idiot and all, I have no idea how something optional is
> introduced into the require.

Now that you know that "blowing up" is really a error being signaled,
The NOERROR parameter should jump at you ;-)

Here, you have two optional parameters.  Since we're interested in the
second, we need to provide the first.

> What do you recommend to a simpleton regarding how to avoid the
> interruption?  Just make sure all is perfect before starting emacs?

So writing:                (require 'some-library nil t) 
or as suggested elsewhere: (require 'some-library nil 'noerror)
since any non null value is true, you will be able to use require
without it signaling any error.  Instead, if there's a problem it will
return nil instead of the symbol of the library.  So you can test it:

(when (require 'some-library nil t)
  (use-that-library))


> Or maybe spend a day or two figuring out how to apply the codified
> documentation.... again... thats' a hard pull for the intellectually
> crippled.

That would be a good investment of your time, indeed.
http://www.gnu.org/software/emacs/manual/
You will have a lot of fun reading the "GNU Emacs manual" and the "GNU
Emacs Lisp reference manual".


-- 
__Pascal Bourguignon__


reply via email to

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