0

There's several centos linux boxes at my workplace.

I've been tasked with creating some form of environment variable tool for them.

The idea is the user runs the tool, with the argument of their project (and perhaps their pythonpath 'mode'), press enter and a) a new variable called "PROJ" is made and b) their PYTHONPATH has a new folder appended. The scope of these variables only lasts as long as they have that terminal session open.

I've seen this at other places I've worked at. But I never dug deep enough to understand it's working, which I'm kicking myself now!

I'm guessing it's a bash script that exports the variable name to the path given. Python does export environment variables, it but it doesn't remain - it's like the export is only applied to child processes of the python script, so when the script ends, the variables end too. This is why I've come to the conclusion it's a bash script.

If so, what's the best way to distribute this tool, so all boxes have the script, preferably aliased so the user isn't typing source <script_location>.sh?

Secondly, what's the best way of checking if arguments are valid? I was thinking of a json file with the correct project codes in them.

Lastly, can I have a mixture of flagged and non-flagged arguments? eg, the user would type something like <tool_name> <project_title> -f where -f would be an additional, optional feature? Should I roll it out to each user's ~/.bashrc?

If there are any examples of what I'm looking for, I'd be incredibly grateful to be pointed in the right direction...

1

You can create sh file that defines a function that updated the environment. The function can be named "tool_name".

Check https://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files -- interactive login shells will source /etc/profile. Check that file on your system and you'll see that it will do something like source every file in a particular directlory. On my ubuntu-based system, it is

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

So, the /etc/profile.d/tool_name.sh file looks like

# create the tool function to update the environment
tool_name() {
    # todo: parse options, validate arguments
    export PROJ=$1
    PYTHONPATH+=":$PROJ/bin"
}

And the users need to nothing special to make it available to them.

I'm not telling you how to distribute this to many boxes. You will need sudo privileges or root access to install to /etc/profile.d

  • There might also be an idea to spawn an interactive shell from a script. This would have the benefit of allowing a user to easily exit the interactive shell to "reset" the environment once they are done using the modified environment. – Kusalananda Sep 27 '18 at 15:10
0

The environment is only ever passed on to child processes; a child process can never directly influence the environment of the parent process.

To set variables in the shell of the user, those need to be set by the shell itself. One way is to "source" a script that sets those variables, i.e. the script is executed by the running shell:

$ source scriptname

If you simply call the script:

$ scriptname

then a new shell (i.e. a new process) is started, and that reads the script, setting the variables in its environment. However as soon as that shell is done with the script, it exits, destroying the newly created environment; hence a waste of time.

Alternatively you could define a shell function via /etc/profile that will set the environment up correctly. Only when the user calls the function will this be done. That way it looks like you're calling some command, which is actually a shell function and hence executed within the same shell instead of a new shell being started.

Within the script or function you can perform whatever checks you need to set up the environment correctly.

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.