I'm looking for a good practice there. I need to store some global config options in my node.js command-line tool.
For example typing in bash:
$: mycommand set myGlobalOption=value
and then I can use myGlobalOption with another commands, is storing this value in environment variable a good solution?
Store this in a configuration file in the user's home directory like ~/.myprog.json. You can't store persistent data in environment variables because those ultimately come from shell configuration files like ~/.bash_profile which are not machine editable. Allowing these values to be set by environment variables is reasonable, but just have the user set them herself and don't bother trying to have a set command like you describe.
You could also just take these options as command line arguments like mycommand --myglobaloption=value and let users who want to always use the same value set up a shell alias like alias mc="mycommand --myglobaloption=value".
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.
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/
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
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).
I'm trying to set a global environment variable by adding it to the .bash_profile.
What can I do (other than restarting), to apply this value globally, so that new processes (such as Eclipse) can access this value?
Also, if my goal is adding a global environment variable, is writing it to the users' .bash_profile the best way, that doesn't require sudo?
If you add something like this to your .bash_profile:
export MY_TEST_VAR=1213222
You can then execute .bash_profile again in the current shell context
. .bash_profile
And your new processes will see this new enviroment variable
Rebooting is not necessary if it's not root's profile you modified. You just need to log off from your desktop, or close all the sessions where you want the environment refreshed.
The user's profile files is the best way to set user-specific variables.
If you want system-wide or group-wide settings, those are best left to root (for system-wide) or a restricted set of users.
You could for example implement a scheme like this: Have files like the following:
/usr/local/etc/my_group.profile
readable by all users in mygroup but writable only by users of group mygroup_admins, and make the system-wide profile script source such files depending on the user's assigned groups. This gives you a bit of flexibility without having to hand out root privileges too much.