From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: test for presence of library Date: Sat, 20 Feb 2010 10:54:14 +0100 Organization: Informatimago Message-ID: <87d4008c6x.fsf@galatea.lan.informatimago.com> References: <87mxz6116b.fsf@galatea.lan.informatimago.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1266662549 18133 80.91.229.12 (20 Feb 2010 10:42:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Feb 2010 10:42:29 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Feb 20 11:42:26 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nimn0-0001kf-93 for geh-help-gnu-emacs@m.gmane.org; Sat, 20 Feb 2010 11:42:22 +0100 Original-Received: from localhost ([127.0.0.1]:59228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nimmz-000696-Kw for geh-help-gnu-emacs@m.gmane.org; Sat, 20 Feb 2010 05:42:21 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 98 Original-X-Trace: individual.net PDiKX9gYTsJK0jxPmr3u2w84lDjvLgofqNbhbaqq2KswlT1LOK Cancel-Lock: sha1:OWIzMzFlODcyZWU0NmQ5NWVkMDMwNjdhMGE2OGU1MmYxNjZlNjU2NA== sha1:FBXHYVqzHT6IB5hjzPSeLj4uGNQ= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (darwin) Original-Xref: news.stanford.edu gnu.emacs.help:176908 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:71975 Archived-At: Harry Putnam 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__