New answers tagged environment-variables
The following three shell snippets are equivalent (as in, they accomplish the same thing, and you have to dig in to observe any different effect): env COLUMNS=%s ps … COLUMNS=%s ps … (export COLUMNS=%s; ps …) All of them set the environment variable COLUMNS to the value %s for the invocation of the ps command. In the shell, the value of COLUMNS, ...
What does env COLUMNS=%s do? It passes the variable COLUMNS with the value %s to the ps command and forgets, i.e. the variable does not affect the subsequent commands. export would cause the variable to be available for subsequent commands too which may or may not be the intent. Saying: FOO=bar command and env FOO=bar command are identical. ...
export -p does not show $_ for the simple reason that the command only shows those variables marked for export, and $_ (being a special parameter and not a variable--yes, the bash documentation makes that distinction) is not marked for export by the shell. While you can assign to _, bash will overwrite its value after each command. bash also seems to ...
$_ does not seem to be an environmental variable in bash, bash only appears to export it into a child process' environment. Inside bash itself it seems to be a normal shell variable. Note however this is not the case when the first command is executed: $ bash -c 'export -p | grep _=' declare -x _="/bin/bash" Afterwards however it shows up as a normal ...
From help export: -p display a list of all exported variables and functions Which would imply that $_ is simply not exported. That also makes sense since $_ is the last argument of the previous command exporting it to a separate shell would not be very useful since it will always be automatically reset depending on the last command run. You can ...
"Are there other commands which prints only the shell variables, without the functions?" In man bash, in section SHELL BUILTIN COMMANDS (in the set section) it says: "In posix mode, only shell variables are listed." (set -o posix; set) I know that the question has been answered but (set -o posix; set) is cleaner then most suggestions.
To do if for all users/shells, depending on distro you could use /etc/environment or /etc/profile. Creating a new file in /etc/profile.d may be preferable if it exists, as it will be less likely to conflict with updates made by the packaging system. In /etc/environment, variables are usually set with name=value, eg: ...
You can add it to the file .profile or .bashrc or your current shell profile file (located in your home directory). Then, each time you open your shell it will be loaded. To change the environmental variable "permanently" you'll need to consider at least these situations: Login/Non-login shell Interactive/Non-interactive shell bash Bash as login shell ...
Is NetworkManager setting it? Assuming you're using it to manage your network connection. Also you can invoke a shell like this in debug mode so you can get some context of other things happening around the setting of this variable. Example $ bash -x + '[' -f /etc/bashrc ']' + . /etc/bashrc ++ '[' '\s-\v\$ ' ']' ++ '[' -z '' ']' ++ case $TERM in ++ '[' -e ...
Tmux expands time formats with strftime in status-left and status-right before it expands #(…) and other sharp escape sequences. So %H:%M is expanded to the local time first, and date runs with an argument that is already numeric. Double the percent signs. set -g status-right "#[fg=white]#S #I:#P #[fg=yellow]:: %d %b %Y #[fg=green]:: #(TZ=America/New_York ...
I am not familiar with tmux but I guess the problem is that #() does not work the same way like $() in the shell. The problem may be solved by forcing the use of a shell: #(bash -c 'TZ=Europe/Belgrade date +%H:%M')
Just put the code in a new file in /etc/profile.d/ and check that /etc/profile has some code that executes every script in that directory. My /etc/profile has: if [ -d /etc/profile.d ]; then for i in /etc/profile.d/*.sh; do if [ -r $i ]; then . $i fi done unset i fi which means the script needs to have a .sh extension
while exported variables make it to the other side using the above 'getstate' function, for some reason they end up not being exported there (as can be seen using a simple os.getenv from python). it seems to work better for me when modifying getstate to be an alias: alias getstate=". ~/environment.tmp"
The problem was that I included the Dense header using: #include "eigen3/Eigen/Dense" That fact, combined with the /home/myname/eigen3 search path has caused the compiler to look for the file: ~/eigen3/eigen3/Eigen/Dense which of course he couldn't find. Changing the #include directive to: #include "Eigen/Dense" solved the problem.
Top 50 recent answers are included