Hot answers tagged

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 ...


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 ...


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 ...


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 ...


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 ...


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.


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 ...


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

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 ...


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


1

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



Only top voted, non community-wiki answers of a minimum length are eligible