Is there a way to unset environment variables with grunt-env? I know I can set them from the module, and there is even a way to set them to a value only if it doesn't exist. However, the project's GitHub page does not seem to show how to unset them. Any solution would be better if it also included a way to unset only if the variable is already set. Suggestions for other modules are welcome, as well.
Is there perhaps a value I could set the variable to, like undefined or null or empty string? Forgive me, I'm not too well-versed in environment variables.
The reason I am asking this is because I am creating an express app, and I may want to set some values, which would be controlled by environment variables, back to the defaults, and this would require either setting the variable to a specific value or unsetting it. I would rather go with unsetting it, if possible, so I don't have to remember which value to set it to.
This plugin is setting env variables only within the grunt process - those variables will not be visible for other processes at all! So you will not be able to set shell environment variables for your express app with this grunt plugin.
I also advice you not to set shell env variables with your build tools, but have them defined in bash file and loaded when the server is booted.
Related
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 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".
I intend to create a set of options in vimscript as flags that I can then set at runtime to change the behaviour of my script.
How can I create custom option variables, other plugins like NERDTree for example seem to be able to do it...
The set of Vim options (i.e. the stuff that you manipulate with :set) is fixed. But plugins use variables, usually named g:PluginName_OptionName or so, to get something very close to options. With the different variable scopes (g:, b:, w:), you can even achieve something like the buffer- or window-local options in Vim: This means that the plugin checks for the existence of the local variable first, and falls back to using the global variable if no local one exists.
Plugins should provide default values for their configuration variables, that can be overridden in the user's .vimrc. This is achieved by a test like this:
if ! exists('g:PluginName_ConfigItem')
let g:PluginName_ConfigItem = 'default value'
endif
If you plan to publish your plugin, be sure to document the variables and what values they can hold.