New answers tagged

3

All shell variables live in the same storage. At startup, all environment variables are imported. When a new command is launched, a new environment if created for this new command. All variables that are marked for export or that have been imported from the original environment are put into this new environment specfic to the new command.


4

If you assign a value that does not influence the environment of the running shell (I do not know whether that is possible at all). The shell uses internal memory for all its variables (at least for the written ones). You can easily see that: env - TESTVAR=foo bash echo $TESTVAR foo TESTVAR=bar echo $TESTVAR bar echo $$ 13833 cat /proc/13833/environ ...


1

As of PAM version 1.2.0, you can use @{HOME} instead of ${HOME} and it will work consistently: https://git.fedorahosted.org/cgit/linux-pam.git/commit/?id=73bdfac8c091492f466342feb8f2f5daa2f4c39b


0

On top of what @cuonglm said, check for references to bash in your .tmux.conf. For example, I was using a typical integration for copying & pasting in iTerm on Mac: set-option -g default-command "reattach-to-user-namespace -l bash" ... which, to function properly with zsh had to be changed to: set-option -g default-command ...


2

The $HOME variable isn't something you should mess with, generally; it's user-dependent. You don't want the user to suddenly have a different home directory! (And if you do, you should edit his home directory that is set in /etc/passwd—which of course requires root permissions.) The $PATH is another matter and should be set in his ~/.bashrc or ...


-1

Just export variables: export NAME1="value1" export NAME2="value2" ./my.install Edit: Doing this is possible from following shells (I know): DASH BASH KSH ZSH Edit 2: Move my.install to my.install.real, and create a new file called my.install: export HOME='SAMPLE VALUE' export PATH='SAMPLE VALUE' ./my.install.real unset HOME unset PATH


4

gcc -print-search-dirs will output the various lists of directories which gcc uses for binaries: its installation directory, the directories where it searches for programs, the directories where it searches for libraries. echo | gcc -v -E - will output the actual path variables (COMPILER_PATH, LIBRARY_PATH) and the directories which gcc uses for header ...


1

Usually, one uses gcc -v for this. gcc -v without any file to compile gives only the compile-time configuration of GCC as well as its default target architecture but when you give it a file to compile (gcc -v test.c), it displays more information. Here is an output example: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/gcc ...


2

This is apparently an old issue (as in 15 years old). The "fix" at them time was: * Note that HOME may not be useful in pam_environment, closes: #109281 The Linux PAM site also says as much: Note that many environment variables that you would like to use may not be set by the time the module is called. For example, HOME is used below several ...


0

Use sudo -E su command which is set them in /etc/environment.


1

Use su - instead, to ensure you inherit the root env.


4

ls -lL /usr/bin/env shows that the symbolic link is broken. That explains why the shebang line isn't working: the kernel is trying, and obviously failing, to execute a dangling symbolic link. /usr/bin/env -> ../../bin/env is correct if /usr and /usr/bin are both actual directories (not symlinks). Evidently this isn't the case on your machine. Maybe /usr ...


-1

Here (Fedora 23) /bin is a symbolic link to /usr/bin; if you have a similar setup, the symbolic link from /usr/bin/env just buys you an infinite loop. Check the relevant packages, i.e. rpm -qf /usr/bin/env /bin/env, and reinstall those (here coreutils, i.e.. yum reinstall coreutils or similar). That should fix any misguided manhandling.


0

The EnvironmentFile option should be set to the full path of the file containing any necessary environment variables needed for proper operation of the executable. Arguments to the executable can be included in the "ExecStart" parameter. You can find more documentation at http://www.freedesktop.org/software/systemd/man/systemd.service.html


4

Your statement has a semicolon where it should have a colon: export PATH=$PATH:$HADOOP_HOME/bin;$HADOOP_HOME/sbin versus export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin A semicolon ; separates statements, not parts of a PATH. The first time you ran the command, it added $HADOOP_HOME/bin to your PATH (which is okay). But it did not add ...


18

They're not expressions, they're filenames for files produced as follows: printenv | sort > printenv.sorted set | sort > set.sorted That's not clear from the documentation so your confusion is understandable! Note that you may need to help diff and grep by forcing them to treat their inputs as text (with -a); environment variables can contain ...



Top 50 recent answers are included