When creating set variables, what is the advantage of adding them to environment? Both are lost at session termination. I know obviously I can add useful stuff to .bashrc that I would want to access via my user.
Just not sure what the advantages would be? how common practice is it? do I need to worry about it? I am talking real life administration uses.
It seems to me like set is a local variable within a class. ENV is obviously global. Maybe the only use is when traversing different shells? How practical is it?
Environment variables are inherited by any process invoked by your shell. That includes both sub-shells and any other commands you invoke.
(Non-environment) shell variables are not.
For example, $TERM needs to be exported, because commands you invoke from your shell (a text editor, a pager, anything that uses a full-screen text display) needs to know what kind of terminal you're using, so it can look up its capabilities in termcap or terminfo. $LANG and similar variables need to be exported so that commands know about the current locale. $PATH needs to be exported so that any commands you invoke can then invoke other commands.
$PS1, the shell prompt, does not need to be exported, because it's relevant only to the current shell (and is typically initialized for new shells).
Related
In a graphical DE, like KDE, what command can be used to add a new environment variable that can be used by any other process?
Note:
1) I'm aware of export A=B, but it only works for subsequent processes started in the same shell that executed the export, processes started else where, like a graphical application such as Chrome, won't be aware of the export.
2) I'm also aware that you can put it into ~/.bash_profile or alike, but that would need a restart/relogin for the setting to take effect.
Is there something like export but have effect for all applications and doesn't require a significant restart?
Your assumption that you need to restart after placing a variable definition (whether through an export statement or otherwise) in ~/.bash_profile, is flawed. You only need to source the file again after making modifications:
source ~/.bash_profile
or the more portable version:
. ~/.bash_profile
Either statement will (re)load any definitions in that file into your current shell. Sourcing is not the same as executing the script: it will modify the environment in the calling shell itself, not a subshell running the script.
A file like ~/.bash_profile may have many other definitions and settings in it that will mess with the shell. It is better to create a small (temporary) snippet with just the variables you want, and source that instead, as #JeremiahMegel suggests.
If you want to change the environment for a single process you run from the command line, you can set the variables on the same command line:
VAR=value /usr/bin/gedit
This will run gedit with the environment variable VAR set to value, but only for that one child process.
Unfortunately, your desktop applications are a bit more static than that. Most of the graphical applications you see in the menus are probably going to be represented by .desktop files in a folder like /usr/share/applications. These files are run in an environment that has almost none of the variables you are expecting. They rely on absolute paths, and most of the configuration is done by pointing the .desktop file to a script that performs its own setup. You can modify some of these files on an individual basis if you absolutely have to, but I would not recommend doing that. If you do insist on messing around with the graphical apps on your desktop, I would recommend making a copy of the desktop files you plan to modify in to ~/.local/share/applications, or whatever the equivalent is on your system. Those files will override anything found in /usr/share/applications and will only affect you.
I'm doing some work using Linux server, after I log on to the server,the tutorial says:
If you need to run any program which will open a window, like xterm, from these servers, you need to set display first.
To do that, I need to execute setenv DISPLAY name:portnum.What does this command really do?If I don't execute this command,what will happen?And what is xterm?
setenv is specific and peculiar to csh and derivatives. The modern portable syntax is
DISPLAY=:0.0
though if your shell is csh or tcsh, this will not work, and you do need setenv after all.
Depending on the use case, you may need to export DISPLAY as well.
Environment variables are a simple way to pass configuration information between programs. The DISPLAY variable indicates to graphical programs on which screen or graphical terminal to display their GUI.
For X Window System, it is a server/client architecture, usually, server side is called display, the tutorials means you should launch server side and specify launch parameter for server side.
read here for more details.
Xterm is just a terminal. And setenv, is used to set Environment variables, which are basically variables used to define the behavior of the terminal. For example, you have the variable PATH, which is used by the terminal to find the path where to execute binaries. Because if you type the command "ls", your terminal has to go into the "env", look for the variable "PATH", and use the value stored in this variable "PATH" to find the path of the ls binary. But I don't know if it's necessary in your situation, could you give more details about the context?
Path is an environment variable but i don't know whether its' a global or local environment variable. I need example for global and local environment variables and their usage in reference to Linux.
Its a question from my paper and i didn't study global or local environment variables. However, I have gone through shell and environment variables. So, i guess one of them (shell and environment) is global and local.
Because you specifically referenced the PATH variable, I'm going to assume you're referring to variables that impact a user in terminal mode on Linux. Even so, these two terms can have various meanings.
An example:
Most linux distros will have a file called /etc/bashrc (or /etc/bash_profile, etc. depending on distro). This file will contain settings variables for the bash shell as determined by the system administrator. These are "global" or "environment" variables, and it includes the PATH variable, but it also sets things like whether or not some commands provide their output in color, what the shell prompt looks like, etc.
Some power-users will not be satisfied with these defaults, and want to change them. They can create a file called /home/poweruser/.bashrc, and inside they can override most if not all of the variables in /etc/bashrc. Another example of this would be creating a custom ~/.vimrc, or even setting variables temporarily on the command line like so:
$ LANG=utf8
$ echo $LANG
utf8
This link has more information on the differences between the two and how to look at what variables are set on your shell: http://howtolamp.com/articles/difference-between-local-and-environment-variables/
This question already has answers here:
How to permanently set $PATH on Linux/Unix [closed]
(24 answers)
Closed 6 years ago.
This is a very interesting question that I stumbled upon when I was creating a command-line application tool for Linux. Unfortunately, the answer on SO is so hidden among the myriad answers to other questions that I decided to ask another question on SO for those who want to modify PATH programmatically.
Grzegorz Żur's answer to another question captures it brilliantly. Unfortunately it was hidden away among many other answers.
There are multiple ways to do it. The actual solution depends on the
purpose.
The variable values are usually stored in either a list of assignments
or a shell script that is run at the start of the system or user
session. In case of the shell script you must use a specific shell
syntax.
System wide
/etc/environment List of unique assignments. Perfect for adding system-wide directories like /usr/local/something/bin to PATH
variable or defining JAVA_HOME.
/etc/xprofile Shell script executed while starting X Window System session. This is run for every user that logs into X Window
System. It is a good choice for PATH entries that are valid for
every user like /usr/local/something/bin. The file is included by
other script so use POSIX shell syntax not the syntax of your user
shell.
/etc/profile and /etc/profile.d/* Shell script. This is a good choice for shell-only systems. Those files are read only by shells.
/etc/<shell>.<shell>rc. Shell script. This is a poor choice because it is single shell specific.
Also, /etc/environment is not a script file, but rather consists of assignment expressions, one per line. Since this file stores the system-wide locale and path settings, it is most oft quoted choice.
Using /etc/profile is not preferred. It exists only to point to /etc/bash.bashrc and to collect entries from /etc/profile.d
User session
~/.pam_environment. List of unique assignments. Loaded by PAM at the start of every user session irrelevant if it is an X
Window System session or shell. You cannot reference other variable
including HOME or PATH so it has limited use.
~/.xprofile Shell script. This is executed when the user logs into X Window System system. The variables defined here are visible to
every X application. Perfect choice for extending PATH with values
such as ~/bin or ~/go/bin or defining user specific GOPATH or
NPM_HOME. The file is included by other script so use POSIX shell
syntax not the syntax of your user shell. Your graphical text editor
or IDE started by shortcut will see those values.
~/.profile Shell script. It will be visible only for programs started from terminal or terminal emulator. It is a good choice for
shell-only systems.
~/.<shell>rc. Shell script. This is a poor choice because it is single shell specific.
For temporary change:
~$ export PATH=$PATH:~/root/scripts
For permanent change, you can add this line to the /etc/environment file like this:
PATH=$PATH:~/root/scripts
Just as the title said, I don't know where does this variable locate. I just know how to change it by typing:
$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libXpm.so.4
Then is it possible to change it in its file?
LD_PRELOAD is an environment variable (part of the "environment" defined by the C library and Unix conventions). That specific variable tells the dynamic linker how to behave.
It is probably not set to anything by default. If you want to give it a default value every time you log in or start up a shell, you can put that export statement in your .profile or .bashrc file (or whatever the equivalent is for your shell of choice). There's probably also a place you could set it in /etc that would apply to all logins or shells started on your system (if you need it to be set for other users too).
If you only need to set it for a specific program though, that may be overkill. Instead, you might want to write a short shell script to set the environment variable up first, then launch the program. E.G.:
#!/bin/bash
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libXpm.so.4
~/my_program_that_needs_a_special_library