accessing environment variable

accessing environment variable

[Stephan Hennig]

Hi,

what is the preferred way to access an environment variable from within
the .emacs file?

I want to avoid writing hard coded paths into my .emacs file that had to
be adjusted after each update of, e.g., gs.  I've found the getenv
function should do what I want:

> getenv is an interactive compiled Lisp function in `env.el'.
> (getenv variable)
>
> Get the value of environment variable variable.
> variable should be a string.  Value is nil if variable is undefined in
> the environment.  Otherwise, value is a string.
>
> This function consults the variable `process-environment'
> for its value.

Since environment variable GS_PROG points to the GhostScript binary,
i.e., is of the pattern "path\to\gs\gswin32c.exe", I've tried various
combinations (quoting, escaping and parenthesizing) of

(getenv GS_PROG)

but I always get an error

> Printing...
> apply: Searching for program: no such file or directory, (getenv GS_PROG)

or similar in the *Message* buffer.  It seems to me getenv isn't
executed, but treated literally in this context.  How do I correctly
refer to an environment variable here?

Best regards,
Stephan Hennig


Windows XP,
This is GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-07-07 on
NEUTRINO

From my .emacs:

;;
;; Emacs Customization
;;

(custom-set-variables
[...]
 '(ps-lpr-command "(getenv GS_PROG)")
[...]

RE: accessing environment variable

[Drew Adams]

> what is the preferred way to access an environment variable from within
> the .emacs file?
>
> > (getenv variable)
> > Get the value of environment variable variable.
> > variable should be a string.
>
> (getenv GS_PROG)

1. (getenv "GS_PROG")
See doc above: "Variable should be a string."

> (custom-set-variables '(ps-lpr-command "(getenv GS_PROG)")

2. ps-lpr-command expects a string that names a program. It does not expect
a Lisp sexp.

Re: accessing environment variable

[Stephan Hennig]

Drew Adams schrieb:

> 1. (getenv "GS_PROG")
> See doc above: "Variable should be a string."

Thanks.


>> (custom-set-variables '(ps-lpr-command "(getenv GS_PROG)")
> 
> 2. ps-lpr-command expects a string that names a program. It does not expect
> a Lisp sexp.

Does that mean there is no way to feed the value of an environment
variable into ps-lpr-command (same for doc-view-ghostscript-program)?

Best regards,
Stephan Hennig

Re: accessing environment variable

[Harald Hanche-Olsen]

+ Stephan Hennig <mailing_list@arcor.de>:

> Drew Adams schrieb:
>
>> 1. (getenv "GS_PROG")
>> See doc above: "Variable should be a string."
>
> Thanks.
>
>
>>> (custom-set-variables '(ps-lpr-command "(getenv GS_PROG)")
>> 
>> 2. ps-lpr-command expects a string that names a program. It does not expect
>> a Lisp sexp.
>
> Does that mean there is no way to feed the value of an environment
> variable into ps-lpr-command (same for doc-view-ghostscript-program)?

No.  I am not intimately familiar with the customization system on
emacs, but you can certainly do it by including

  (setq ps-lpr-command (getenv "GS_PROG"))

in your .emacs file.

Things get a bit trickier if those environment variables don't just
name a program, but names program arguments as well.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: accessing environment variable

[Stephan Hennig]

Harald Hanche-Olsen schrieb:

>> Does that mean there is no way to feed the value of an environment
>> variable into ps-lpr-command (same for doc-view-ghostscript-program)?
> 
> No.  I am not intimately familiar with the customization system on
> emacs, but you can certainly do it by including
> 
>   (setq ps-lpr-command (getenv "GS_PROG"))
> 
> in your .emacs file.

Thank you and Drew!  It works now.


> Things get a bit trickier if those environment variables don't just
> name a program, but names program arguments as well.

Those are hard-coded in ps-lpr-switches and that's ok for me.  Thanks again!

Best regards,
Stephan Hennig