;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.
-(in-package "SB-IMPL")
+(in-package "SB-IMPL") ;(SB-IMPL, not SB!IMPL, since we're built in warm load.)
\f
;;;; hacking the Unix environment
;;;;
;;;; visible at GENESIS time.
(def-alien-variable "environ" (* c-string))
+(push (lambda ()
+ ;; We redo this here to protect ourselves from this scenario:
+ ;; * Build under one version of shared lib, save a core.
+ ;; * Load core under another version of shared lib. ("Now
+ ;; where was environ again?" SIGSEGV, etc.)
+ ;; Obviously it's a KLUDGE to do this hack for every alien
+ ;; variable, but as it happens, as of sbcl-0.7.0 this is the
+ ;; only alien variable used to implement SBCL, so it's not
+ ;; worth coming up with a general solution. (A general
+ ;; solution would be nice for users who want to have their
+ ;; alien code be preserved across a save/load cycle, but this
+ ;; problem with alien variables is only one of several
+ ;; problems which'd need to be solved before that can happen.)
+ (def-alien-variable "environ" (* c-string)))
+ *after-save-initializations*)
(defun posix-environ ()
"Return the Unix environment (\"man environ\") as a list of SIMPLE-STRINGs."
;; "path:" defined in sbcl-0.6.10. It would probably be
;; reasonable to restore Unix PATH searching in SBCL, e.g.
;; with a function FIND-EXECUTABLE-FILE-IN-POSIX-PATH.
- ;; (I don't want to do it with search lists the way
- ;; that CMU CL did, because those are a non-ANSI
- ;; extension which I'd like to get rid of. -- WHN)
+ ;; CMU CL did it with a "PATH:" search list, but CMU CL
+ ;; search lists are a non-ANSI extension that SBCL
+ ;; doesn't support. -- WHN)
(pfile (unix-namestring program t))
(cookie (list 0)))
(unless pfile