Tag Info

Hot answers tagged

9

What you describe is an anti-exploitation feature called Address Space Layout Randomization (ASLR). Basically, the kernel puts the very top address of a program's function call stack at a slightly different ("random") address every time the kernel loads the program's ELF file from disk. The addresses in argv and the environment variables, of which your ...


6

You didn't specify a shell. So, I will assume bash. The next issue is: did you set it for your user only or system-wide? If you set it as your user, then run: grep JAVA_HOME ~/.bash_profile, ~/.bash_login ~/.profile ~/.bashrc If you set it system-wide, then it may vary with distribution but try: grep JAVA_HOME /etc/profile /etc/bash.bashrc ...


5

Am I right that read first second is a subprocess of the current shell process? If yes, why don't we need export IFS=";"? No, read is a bash bultin function. No subshell or subprocess is created here, so we don't need to export IFS. why is IFS empty? Because you don't use double quote. You have changed value IFS to ;, so when you echo $IFS, ...


4

On Red Hat and CentOS systems, it is defined in /etc/profile.d/less.sh. On version 5, this contains # less initialization script (sh) [ -x /usr/bin/lesspipe.sh ] && export LESSOPEN="${LESSOPEN-|/usr/bin/lesspipe.sh %s}" On other systems, such as version 7, the value may be ||/usr/bin/lesspipe.sh %s; there is a slightly different interpretation ...


3

With zsh: zsh -xl In bash: PS4='+$BASH_SOURCE> ' BASH_XTRACEFD=7 bash -xl 7>&2 That will simulate a login shell and show everything that is done (except in areas where stderr is redirected with zsh) along with the name of the file currently being interpreted. So all you need to do is look for JAVA_HOME in that output. (you can use the script ...


2

It's a bad idea if it doesn't work. I think your concern about profile.d not running unless someone logs in is legitimate. Put an init script in /etc/rc.d/init.d (I think this is the correct directory for Red Hat; in Ubuntu it's /etc/init.d) to start your daemon. In this script you can declare/define any variables you need and when you start the daemon ...


2

If you insert echo "prevexit=3" > ~/.prevexit at the end of your crontab initiated command, then you can use: source ~/.prevexit close to the top of all the scripts that need to include the value, and use it in the rest of those scripts as $prevexit. You should of course replace 3 with the real value you want to share.


2

If zsh is you login shell: zsh -xl With bash: PS4='+$BASH_SOURCE> ' BASH_XTRACEFD=7 bash -xl 7>&2 That will simulate a login shell and show everything that is done (except in areas where stderr is redirected with zsh) along with the name of the file currently being interpreted. So all you need to do is look for the name of your environment ...


1

Arrays aren’t environment variables, and so are not (and cannot be) inherited by children processes (such as scripts) from their parents.  You must “create [your array] from scratch every time you run your script.”  I don’t understand why you view this as a hardship.  If the values are constant, as you say, then all that needs to happen is for those values ...


1

In most configurations, sudo strips most environment variables. You can see the sudo configuration by running sudo -V as root (so sudo sudo -V as a user with sudo permissions). On Ubuntu, variables are stripped except from a small list, and EDITOR and VISUAL are not in the list to preserve. So when you run sudo somecommand, your per-user editor preferences ...


1

IFS=\;; set -- $IFS; echo $#; echo "$*" 1 ; IFS=; set -- $IFS; echo $#; echo "$*" 0 #there doesn't seem to be anything here As you can see - $IFS is not empty in the first case - it contains exactly one field separator. When the shell expands an unquoted variable it splits its value on the delimiters defined in $IFS. In this way each variable is, ...


1

In answer to why IFS is empty. It is not. But the value in IFS is changing the behaviour of the shell. Below is not an explanation but just the result of my experiments using bash on Debian Gnu+Linux. a=";"; echo $a produces ;. IFS=";"; echo $IFS produces blank line. IFS=";"; echo "$IFS" produces ;. Now a=";"; echo $a produces blank line, but IFS=" "; ...


1

If we type type read we get read is a shell builtin. Therefore it is not run as a sub-process.


1

Environment variables are plenty secure. What the question you linked to is saying is that if the system is compromised, the only security benefit of using environment variables over a configuration file is obscurity. Meaning that if someone has gained root access, they can get to both. Whether using environment variables for secret data is considered ...


1

As Gilles explained in a very comprehensive answer to a similar question on security.stackexchange.com, process environments are only accessible to the user that owns the process (and root of course).


1

To directly answer your question, it's only a bad idea if it doesn't work. So my direct answer is "no", if it doesn't work, "yes" if it works. Did you try it? That is, have you confirmed that profile.d doesn't run on your system if no one logs in? As a suggestion of how to make it work: Edit the rc.local file in the same way, to ensure the settings are ...


1

You know how to set the variable in a shell, but for the record you can write: export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on' and all programs you start from this shell session after that will have the variable set. If you want it to be set for every shell you start afterwards, add that line to ~/.profile as well. In that case it will apply to ...



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