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 :

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?

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

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

printenv

to show your current environment. That’s to check if the setting you made is working.

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.

cat ~/.bashrc

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

/etc/skel

Check what is in inside that directory

ls -la /etc/skel

or without all other info on those files. (assuming bash is the login shell)

shopt -s dotglob
printf '%s
' /etc/skel/*

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

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, …)

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)

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).

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.

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:
https://i.imgur.com/4jnEUx2.jpg
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.

Hi
So the other terminal is not sourcing it…

In the one that’s not working run;


. .profile <press enter>
echo $COAT_FILES_PATH

@Malcolm : with those instructions the other terminal started “seeing” the variables. So the question is - how can I use this knowledge to make it work with 3D Coat?

Hi
So it would seem to be a bug with Tilix in how it’s reading the user profile (in this case it isn’t) in openSUSE, I would suggest a bug report against Show devel:languages:D / tilix - openSUSE Build Service

You could create a start script for you app in ~/bin that runs the above then starts the app…

thx Malcolm. I’ve created .sh script with the following:


. ~/.profile && ./3d-coat-64

and it made 3D Coat see the variable. So I wonder whether it is Tilix and 3D Coat’s bug or whether it is a matter of Opensuse handling some things differently than other distros.
THANK YOU!

Hi,

Only one suggestion. first test for ~/.profile if it is really there before sourcing it.

test -f ~/.profile && . ~/.profile && ./3d-coat-64 

Yes we all know that ~/.profile is there but sometimes bad things just happen you know :slight_smile: