17

On my system, for apps that use SDL, I need to set an environmental variable:

export SDL_AUDIODRIVER=alsa

to get the sound to work properly. How do I set up my GNOME session so that this variable is present for all applications (so if I run an application through Nautilus, or use DBGL, the apps work properly)?

EDIT:

Configuration files I have set (and reset my machine after each) to no avail:

  • .xsession
  • .xsessionrc
  • .gnomerc
  • .bash_profile
  • .profile<-- This works in the general case, but not when your distro is setting the variable elsewhere.
  • /etc/profile
7
  • Are you sure this needs to be an environment variable? Seems like it might be some other kind of setting. Have you dug around in the system sound settings applet?
    – codeLes
    Aug 6, 2009 at 15:29
  • It does indeed. This is how SDL figures out what backend to use. I wish it just used a configuration file, but SDL is fairly consistent in its use of environmental variables to dictate behaviour.
    – Bernard
    Aug 6, 2009 at 15:31
  • have you seen this: modarchive.org/forums/index.php?topic=1879.0
    – codeLes
    Aug 6, 2009 at 15:35
  • 1
    Well yeah, it's a choice between recompiling SDL or setting an environmental variable. I think I'm making the right choice. :p This works (i.e., in a shell, it works) it's just the thorny issue of getting GNOME to propagate the variable for apps not started from a shell that's the issue. Thank you for your continuing help.
    – Bernard
    Aug 6, 2009 at 15:45
  • What distro is this in?! (I agree that the config for gdm is really hard to follow, so my first thought, "just look in /etc/gdm/ and read the scripts" is a lot of pain.) Here, .profile seems to work just fine. (debian/testing) Aug 7, 2009 at 0:10

5 Answers 5

6

It could be that the SDL_AUDIODRIVER variable is being unset somewhere. One strategy I use for problems with things related to startup scripts is to put in debug echo statements that is simple to enable/disable by creating/deleting a file. You could start by adding

debug_msg() {
        test -f $HOME/.debug && echo "$@" 1>&2
}

debug_msg "running ~/.bashrc ($0), SDL_AUDIODRIVER = '$SDL_AUDIODRIVER'"

to .bashrc, .bash_profile, .profile and /etc/profile to see what value it has and if/where it is changing.

2
  • Mmm, that's my current thoughts as well. It's set to 'pulse', and that must be being set somewhere by OpenSUSE. I'll do some detective work when I get home.
    – Bernard
    Aug 14, 2009 at 3:58
  • If anyone else is looking for an answer to the OP, this answer does not address it. It is useful debugging info but is not the answer,
    – RichieHH
    Aug 14, 2020 at 2:18
9

https://help.ubuntu.com/community/EnvironmentVariables talks about four places where we can set the environment variables:

  • ~/.pam_environment - […] It is not a script file, but rather consists of assignment expressions, one per line. […] requires a re-login in order to initialize the variables. […]
  • ~/.profile - This is probably the best file for placing environment variable assignments, since it gets executed automatically by the DisplayManager during the start-up process desktop session as well as by the login shell when one logs-in from the textual console.
  • ~/.bash_profile or ~/.bash_login - If one of these file exist, bash executes it rather then "~/.profile" when it is started as a login shell. (Bash will prefer "~/.bash_profile" to "~/.bash_login"). However, these files won't influence a graphical session by default.
  • ~/.bashrc - Because of the way Ubuntu currently sets up the various script files by default, this may be the easiest place to set variables in. The default configuration nearly guarantees that this file will be executed in each and every invocation of bash as well as while logging in to the graphical environment. However, performance-wise this may not be the best thing to do since it will cause values to be unnecessarily set many times.

http://userbase.kde.org/Session_Environment_Variables/en suggests this place for KDE:

KDE will execute any script it finds in $HOME/.kde/env whose filename ends in .sh, and it will maintain all the environment variables set by them. It is important that any variable you want to set must be also exported.

https://help.ubuntu.com/community/ComposeKey#XIM suggests modifying ~/.gnomerc or ~/.Xsession.

2
  • 1
    ~/.pam_environment is not sourced. Now in 2020, despite documention and enabling user_readenv it still is not sourced.
    – RichieHH
    Aug 14, 2020 at 2:20
  • Note that this does not apply to GNOME on Wayland; see this answer to a different question.
    – sjy
    Sep 12, 2020 at 8:51
1

Create a .gnomerc file in your $HOME which is a shell script (like .bashrc) which sets all the variables you want.

3
  • 1
    This isn't working for me, unfortunately.
    – Bernard
    Aug 6, 2009 at 14:53
  • Have you tried opening gnome-terminal and confirmed it doesn't show up in env? Aug 6, 2009 at 15:24
  • 2
    @Mike: it's in my .bashrc so it would show up, but it would be inaccurate. Emacs and M-x getenv confirms that it is not being overridden for GUI apps.
    – Bernard
    Aug 6, 2009 at 15:27
0

Have you tried creating the environment variable int .profile or /etc/profile?

That should work and should already exist. Unlike .bashrc which is per terminal session, these are initiated at login to your session.

2
  • Alas, no effect.
    – Bernard
    Aug 6, 2009 at 15:05
  • It depends on the login manager.
    – RichieHH
    Aug 14, 2020 at 2:21
0

Some answers do not apply to Gnome. Some others may not work now.

See Definition of user service environment.

You can create (for yourself) a file like ~/.config/environment.d/*.conf and define variables therein.

Example (for all users)

% more /etc/environment
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#

EDITOR=/usr/bin/nano

From man pam_env:

PAM_ENV(8)                     Linux-PAM Manual                     PAM_ENV(8)

NAME
       pam_env - PAM module to set/unset environment variables

This will set environment at login, update needs logout login.

It will work with Gnome but is apparently more generally linked to systemd.

From Wikipedia:

systemd is a software suite that provides an array of system components for Linux operating systems. The main aim is to unify service configuration and behavior across Linux distributions. Its primary component is a "system and service manager" — an init system used to bootstrap user space and manage user processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.