Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Setting up environment variables

  1. #1

    Default Setting up environment variables

    I'm trying to set up system variables for 3DCoat (3d sculpting and texture painting app) so it won't mess my home folder. TO do this I've added :

    Code:
    export COAT_FILES_PATH="/home/username/myapps/3dcoatdata"
    to the /etc/profile file .
    The problem is some apps see this variable , some don't. For example when I type echo $COAT_FILES_PATH in Gnome's terminal I get correct response. But when I do the same in Tilix I get blank space.
    And sadly the same goes for 3DCoat - it does not see this setting.
    The same config on Centos works.

    So how should I set those variables under OpenSUSE in a way that it would make them recognizable by all apps?

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,483
    Blog Entries
    3

    Default Re: Setting up environment variables

    The "/etc/profile" is complex. Perhaps not all parts are run. That is run by all users. If you want an environment setting just for yourself, then best to do it in your personal bash startup file.

    What you should do, is create a ".profile" in your home directory, and put the line there. And it should be seen after your next login.

    However, check
    Code:
    man bash
    It will run either ".bash_profile" or ".bash_login" or ".profile" from a login shell. I think it checks for those files in that order and runs the first of them that it sees. So create only one of those three files.

    Your Xwindows startup should run your shell so that the appropriate startup file is called during session startup (after login).

    Once that is setup, you can open a terminal session ("konsole" or "gnome-terminal" or whatever is appropriate for your desktop), and run the command
    Code:
    printenv
    to show your current environment. That's to check if the setting you made is working.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  3. #3

    Default Re: Setting up environment variables

    Hi,

    Assuming of course that the login shell of the user in question is bash (which is the default for openSUSE), then you can just probably look at what the ~/.bashrc file has to say.

    Code:
    cat ~/.bashrc

    By the way the default files for a newly created user is inside the directory

    Code:
    /etc/skel
    Check what is in inside that directory

    Code:
    ls -la /etc/skel
    or without all other info on those files. (assuming bash is the login shell)

    Code:
    shopt -s dotglob
    Code:
    printf '%s\n' /etc/skel/*
    "Unfortunately time is always against us" -- [Morpheus]

    .:https://github.com/Jetchisel:.

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,117
    Blog Entries
    2

    Default Re: Setting up environment variables

    To the @OP,
    What are you trying to accomplish?
    To my eye, it looks like you are creating a PATH to your 3DCoat application data files, and that location is typically set within the application by the Application Developers.

    So unless the app Developers did something completely out of character, I can't think of a legitimate reason for doing what you are doing manually.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  5. #5
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,980

    Default Re: Setting up environment variables

    Quote Originally Posted by tsu2 View Post
    So unless the app Developers did something completely out of character, I can't think of a legitimate reason for doing what you are doing manually.

    TSU
    I do not agree. It is very often the case that applications have it in their documentation that things can be configured away from the deafults by using process environment variables.

    Even a mundane tool as ls has in it's man page:
    Using color to distinguish file types is disabled both by default and with --color=never. With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it.
    And from man zypper (a well know application program in openSUSE):
    /etc/zypp/zypp.conf
    ZYpp configuration file affecting all libzypp based applications. See the comments in the file for desciption of configurable properties. Many locations of files and directories listed in this section are configurable via zypp.conf. The location for this file itself can be redefined only by setting $ZYPP_CONF in the environment.
    And many, may more. Thus I doubt the "something completely out of character".

    In any case, the OP is just following the documentation of his application.

    =================

    To the OP

    I hope you understand how process environment variables work. They are only inherited by the child processes of a process. Thus, for the CLI, when they are set in /etc/profile (if they are for the benifit of all users) or ~/.profile (if they are set and used by a particular user), they are in the shell process and thus available to all processes started from that CLI session (specially login sessions).
    For bash, you can also set them in .bashrc. But mind when the one or the other is used (from man bash):
    INVOCATION

    A login shell is one whose first character of argument zero is a -, or one started with the --login option.

    An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.

    The following paragraphs describe how bash executes its startup files. If any of the files exist but cannot be read, bash reports an error. Tildes are expanded in file names as described below under Tilde Expansion in the EXPANSION section.

    When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

    When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.

    When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc then ~/.bashrc when those files exist and are readable. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.
    In a GUI session this might be different. It depends if your DE setup uses e.g. /etc/profile and .profile. I doubt a GUI login will ever look at the specific bashrc or any other shell specific files there may exist for the many shells there are (c-shell, ksh, tsh, .....)
    Henk van Velden

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,980

    Default Re: Setting up environment variables

    Quote Originally Posted by Pshemas View Post
    Code:
    export COAT_FILES_PATH="/home/username/myapps/3dcoatdata"
    to the /etc/profile file .
    BTW, this is a very contradictory action. You set in a system wide configuration file that something is based in within the home directory of user username. I doubt that other users then user username have access to that.

    Are you sure that that isn't something restricted to user username and thus should be in /home/username/.profile. Of course done by the user username himself, while now root is needed to make that change that influences all users.
    Henk van Velden

  7. #7

    Default Re: Setting up environment variables

    Quote Originally Posted by hcvv View Post
    BTW, this is a very contradictory action. You set in a system wide configuration file that something is based in within the home directory of user username. I doubt that other users then user username have access to that.

    Are you sure that that isn't something restricted to user username and thus should be in /home/username/.profile. Of course done by the user username himself, while now root is needed to make that change that influences all users.
    Yeah, I understand that setting it globally is less than ideal - but on Centos it is only thing (edit in /etc/profile) that did the trick. And I'm not worried that much as only one user (me) will have access to this app.
    I'm going nuts over this - I can't get it to work on OpenSUSE , thus the app crapifies my home folder with 4 additional folders that really shouldn't have been stored there. Sadly it is not uncommon when it comes to 3d apps - but in most you can get around it by using env variables.
    Here's a quote from 3D Coat manual - maybe someone will have a hint howto set it so 3d Coat will see the variable:

    To change the location of 3D-Coat user data files under Linux which by default are located in $HOMEfolder, set environment variable COAT_FILES_PATH with full path. Because 3D-Coat is GNOMEapplication that environment variable should be defined globally to GNOME. Variables which are definedin .bashrc file are not visible to GNOME applications. You can edit appropriate script files by entering inTerminal:
    $ gedit .profile (Ubuntu)
    # gedit /etc/profile (CentOs)

  8. #8
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,652
    Blog Entries
    15

    Default Re: Setting up environment variables

    Hi
    The user ~/.profile should work fine (your env variable does), I'm a GNOME user and never had issues.

    Perhaps it's in the actual code that isn't looking in ~/.profile (maybe a distribution check).
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  9. #9
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,980

    Default Re: Setting up environment variables

    I am not a Gnome user, but when the documentation says that Gnome uses /etc/profile and ~/.profile when starting, then I tend to believe that. The variable then should be available in all offspring processes from that session (except when changed/undone by some process in between).

    And as malcomlewis, as a long time Gnome user, says he never had issues with comparable cases, then there must be something beyond our understanding.

    I know not enough of Ubuntu to understand why one can not use ~/.profile there, but as the application docs say it uses both, it should not make any difference where it is (apart from the argument I gave earlier). Even if it is in both.
    Henk van Velden

  10. #10

    Default Re: Setting up environment variables

    I'm still struggling with this. I know in theory setting it up in ~/.profile should work. But the problem is it does not. Or rather it "misbehaves" - check out this pic:

    Tilix does not see the variable, while Gnome Terminal does. Sadly 3D Coat doesn't belong to the latter and thus it pushes all config folders into my main Home folder - which is bad.
    I'm struggling with understanding how different distros tackle this - on Centos setting it up in /etc/profile does the trick, on Ubuntu ~/.profile is the way to go.
    Any ideas where should I try to add this variable on OpenSUSE?

    Apart from echo command I've tried printenv command. The result is the same - Tilix does not see the variable, Gnome Terminal does. Weird.

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •