[clue] env variables
Chris Fedde
chris at fedde.us
Tue Jun 25 09:47:26 MDT 2013
Reading through the /etc/rc.d/rc script and /etc/init.d/functions also
provide good examples of many of the topics discussed on this thread.
On Tue, Jun 25, 2013 at 9:29 AM, Quentin Hartman <qhartman at gmail.com> wrote:
> I use #!/bin/bash explicitly because I tend to use bash-isms in my scripts
> and I'd rather not have it fail part way because I'm using a strictly POSIX
> interpreter on accident. I'd prefer it to not run at all if bash isn't
> present. If you are diligent about using only POSIX features, then yes,
> using #!/bin/sh is a better choice.
>
> QH
>
>
> On Tue, Jun 25, 2013 at 9:04 AM, Stephen Queen <svqueen at gmail.com> wrote:
>
>> When sourcing a file #!/bin/bash has no effect. It looks to me as if it
>> is seen as a comment. For fun try this:
>> cat my_fun
>> #!/bin/foo
>> export BAR=Hello
>>
>> Now source it
>> . my_fun
>> No error messages. Now
>> $ echo $BAR
>> Hello
>>
>> So you can add #!/bin/bash, to a file you are going to source, but it has
>> no effect.
>> Though if you are always going to add the interpreter to the first line
>> #!/bin/sh is a better choice. It is more portable. It is usually a link to
>> a default shell, whereas bash is not necessarily installed on all systems.
>> A lot of embedded systems don't use bash.
>>
>>
>> A good example of a sourced file on a debian system would be
>> /lib/init/vars.sh. It is sourced by a good number of the start up scripts.
>>
>> Steve
>>
>>
>> On Mon, Jun 24, 2013 at 5:03 PM, Quentin Hartman <qhartman at gmail.com>wrote:
>>
>>> Just a note that removing the #! statement at the top of the file is
>>> usually a bad idea. That doesn't directly start a new shell, that tells the
>>> system (not sure if it's bash itself, or if it's a kernel thing) which
>>> interpreter to use for the script. You can get weird results if you leave
>>> that out and make the script executable.
>>>
>>> It does though create a new subshell as was mentioned, which always
>>> happens with script execution (having nothing to do with #!), which is why
>>> those env_vars don't show up in the parent shell. In order to get them to
>>> show up in the parent shell, you have to source them from the parent shell:
>>>
>>> 04:57 PM:qhartman at qhstation$ cat foo.sh
>>> #!/bin/bash
>>> export FOO=bar
>>>
>>> CWD:~
>>> 04:57 PM:qhartman at qhstation$ ./foo.sh
>>>
>>> CWD:~
>>> 04:57 PM:qhartman at qhstation$ echo $FOO
>>>
>>>
>>> CWD:~
>>> 04:57 PM:qhartman at qhstation$ source foo.sh
>>>
>>> CWD:~
>>> 04:58 PM:qhartman at qhstation$ echo $FOO
>>> bar
>>>
>>>
>>> If you need to have those vars set outside of the context of the script
>>> you are running, you need to add or modify those vars in the appropriate
>>> user's login shell config (usually .bashrc), and then the next time that
>>> user invokes a shell they will be set how you want.
>>>
>>>
>>> On Mon, Jun 24, 2013 at 3:28 PM, Mark G. Harvey <markgharvey at yahoo.com>wrote:
>>>
>>>>
>>>>
>>>> so removing #!/bin/bash/ at the top of the script to stay within the
>>>> same shell session doesn't make any detectable difference
>>>>
>>>> I also added sourcing the file where the variables are set ( # source /etc/profile.d/00_jdk.sh
>>>> )
>>>>
>>>> the variables PATH and JAVA_HOME show up correct when the script is
>>>> running ... but when finished, the variables are still not changed
>>>>
>>>> [root at 87148-mondev01 ~]# echo $PATH
>>>> /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
>>>> ... should be appended with /usr/java/jdk1.7.0_21/bin
>>>> [root at 87148-mondev01 ~]# echo $JAVA_HOME
>>>> ... should have an entry /usr/java/jdk1.7.0_21/bin ... but it is blank
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* "dennisjperkins at comcast.net" <dennisjperkins at comcast.net>
>>>> *To:* CLUE's mailing list <clue at cluedenver.org>
>>>> *Sent:* Monday, June 24, 2013 2:56 PM
>>>>
>>>> *Subject:* Re: [clue] env variables
>>>>
>>>> The proper place for these might be in one of the Bash config files.
>>>>
>>>> ------------------------------
>>>> *From: *"Stephen Queen" <svqueen at gmail.com>
>>>> *To: *"Mark G. Harvey" <markgharvey at yahoo.com>, "CLUE's mailing list" <
>>>> clue at cluedenver.org>
>>>> *Sent: *Monday, June 24, 2013 2:37:49 PM
>>>> *Subject: *Re: [clue] env variables
>>>>
>>>> When you add
>>>> #!/bin/bash
>>>> to the top of your script, you are starting a new shell. When the
>>>> script completes, it exits that shell. Instead "source" you environmental
>>>> variables. Create a file my_env that contains your export commands
>>>> # cat my_env
>>>> export JAVA_HOME=/usr/java/jdk1.7.0_21
>>>> export PATH=$PATH:/usr/java/jdk1.7.0_21/bin
>>>>
>>>> Then source the file
>>>> . my_env
>>>> (space between . and my_env, does not need to be executable).
>>>> Now when you
>>>> # echo $JAVA_HOME
>>>> usr/java/jdk1.7.0_21
>>>> #
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 24, 2013 at 1:54 PM, Mark G. Harvey <markgharvey at yahoo.com>wrote:
>>>>
>>>> CLUE experts,
>>>>
>>>> This puzzle is likely simple for you folks, but it has me stumped.
>>>> I've done considerable digging but have found mixed advice.
>>>>
>>>> I've created a script to download from a local repo via wget an rpm to
>>>> install JDK ... no problem there.
>>>>
>>>> Here's the part I can't get right ... setting the variables so I can
>>>> run scripts to install Tomcat ... Any attempt will bomb if it can't find
>>>> /usr/java/jdk1.7.0_21/bin
>>>>
>>>>
>>>> # set JAVA_HOME variable ... tried in vain
>>>> echo "setting JAVA_HOME variable variable for the session"
>>>> JAVA_HOME=/usr/java/jdk1.7.0_21
>>>> # export JAVA_HOME variable ... tried in vain
>>>> echo "exporting JAVA_HOME variable variable for the session"
>>>> export JAVA_HOME=/usr/java/jdk1.7.0_21
>>>> echo "JAVA_HOME variable: $JAVA_HOME"
>>>>
>>>> # set PATH variable for the session ... tried in vain
>>>> echo "setting PATH variable for the session"
>>>> PATH=$PATH:/usr/java/jdk1.7.0_21/bin
>>>> # export PATH variable for the session
>>>> echo "exporting PATH variable for the subsequent sessions & processes"
>>>> export PATH=$PATH:/usr/java/jdk1.7.0_21/bin
>>>> echo "show PATH variable: $PATH"
>>>>
>>>> sleep 3 # wait
>>>>
>>>> # create script to set JAVA_HOME & PATH variables in
>>>> /etc/profile.d/00_jdk.sh script for all accounts
>>>> # use echo command with single quotes to write the literal statement to
>>>> the script
>>>> touch /etc/profile.d/00_jdk.sh
>>>> echo '#!/bin/bash' >> /etc/profile.d/00_jdk.sh
>>>> echo '# set JAVA_HOME in /etc/profile.d/00_jdk.sh script for all
>>>> accounts' >> /etc/profile.d/00_jdk.sh
>>>> echo 'JAVA_HOME=/usr/java/jdk1.7.0_21' >> /etc/profile.d/00_jdk.sh
>>>> echo '# set PATH in /etc/profile.d/00_jdk.sh script for all accounts'
>>>> >> /etc/profile.d/00_jdk.sh
>>>> echo 'PATH=$PATH:/usr/java/jdk1.7.0_21/bin' >> /etc/profile.d/00_jdk.sh
>>>>
>>>>
>>>> sleep 3 # wait
>>>>
>>>> echo "review contents of /etc/profile.d/00_jdk.sh"
>>>> cat /etc/profile.d/00_jdk.sh
>>>>
>>>>
>>>> ... results of install ... added some blank lines for readability ...
>>>>
>>>> [root at 87148-mondev01 ~]# ./DEV_install_jdk1.7-1.0.0.sh<http://dev_install_jdk1.7-1.0.0.sh/>
>>>>
>>>> installation: Oracle/Sun jdk 1.7 64-bit
>>>> remount /tmp with execute privledge
>>>> changed to /tmp
>>>> Pulling package from Artifactory Repo Management Server
>>>> --2013-06-24 13:24:38--
>>>> https://<RepoHost>/artifactory/simple/ext-release-local/oracle/jdk/7u21-linux/jdk-7u21-linux-x64.rpm
>>>> Resolving <RepoHost>... 10.33.44.10
>>>> Connecting to <RepoHost>|10.33.44.10|:443... connected.
>>>>
>>>> HTTP request sent, awaiting response... 200 OK
>>>>
>>>> Length: 85388149 (81M) [application/x-rpm]
>>>> Saving to: “jdk-7u21-linux-x64.rpm”
>>>>
>>>> 100%[=======================================================================================================================================>]
>>>> 85,388,149 52.7M/s in 1.5s
>>>>
>>>> 2013-06-24 13:24:40 (52.7 MB/s) - “jdk-7u21-linux-x64.rpm” saved
>>>> [85388149/85388149]
>>>>
>>>> jdk downloaded
>>>> check /tmp/ contents for jdk
>>>> -rw-r--r--. 1 root root 85388149 Jun 6 16:46 jdk-7u21-linux-x64.rpm
>>>> install jdk rpm
>>>> Preparing... ###########################################
>>>> [100%]
>>>> package jdk-2000:1.7.0_21-fcs.x86_64 is already installed ........
>>>> due to subsequent running of this script
>>>> install jdk complete
>>>>
>>>> setting JAVA_HOME variable variable for the session
>>>> exporting JAVA_HOME variable variable for the session
>>>>
>>>> ... when tested in the script, the correct answer shows up ...
>>>>
>>>> JAVA_HOME variable: /usr/java/jdk1.7.0_21
>>>>
>>>> setting PATH variable for the session
>>>> exporting PATH variable for the subsequent sessions & processes
>>>>
>>>> ... when tested in the script, the correct answer shows up ...
>>>>
>>>>
>>>> show PATH variable:
>>>> /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/java/jdk1.7.0_21/bin:/usr/java/jdk1.7.0_21/bin
>>>>
>>>> review contents of /etc/profile.d/00_jdk.sh
>>>> #!/bin/bash
>>>> # set JAVA_HOME in /etc/profile.d/00_jdk.sh script for all accounts
>>>> JAVA_HOME=/usr/java/jdk1.7.0_21
>>>> # set PATH in /etc/profile.d/00_jdk.sh script for all accounts
>>>> PATH=$PATH:/usr/java/jdk1.7.0_21/bin
>>>> remount /tmp removing execute privledge
>>>> finished
>>>>
>>>>
>>>> ... after script runs, when tested from CLI, variables not not correct
>>>> ...
>>>>
>>>> [root at 87148-mondev01 ~]# echo $JAVA_HOME
>>>>
>>>> [root at 87148-mondev01 ~]# echo $PATH
>>>> /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
>>>>
>>>>
>>>>
>>>> [root at 87148-mondev01 ~]# exit
>>>> logout
>>>>
>>>> [vwadmin at 87148-mondev01 ~]$ su -
>>>> Password:
>>>>
>>>>
>>>> ... now the variable additions show up ... they come from
>>>> the /etc/profile.d/00_jdk.sh script created as part of the JDK download &
>>>> install ...
>>>>
>>>> [root at 87148-mondev01 ~]# echo $PATH
>>>>
>>>> /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/java/jdk1.7.0_21/bin:/root/bin
>>>>
>>>> [root at 87148-mondev01 ~]# echo $JAVA_HOME
>>>> /usr/java/jdk1.7.0_21
>>>>
>>>>
>>>>
>>>> ... How can I get the variables to be available for the current root
>>>> session & usable for subsequent installations? Trying to avoid the logout
>>>> / login ...
>>>>
>>>>
>>>>
>>>> Thanks for your help.
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list: clue at cluedenver.org
>>> For information, account preferences, or to unsubscribe see:
>>> http://cluedenver.org/mailman/listinfo/clue
>>>
>>
>>
>> _______________________________________________
>> clue mailing list: clue at cluedenver.org
>> For information, account preferences, or to unsubscribe see:
>> http://cluedenver.org/mailman/listinfo/clue
>>
>
>
> _______________________________________________
> clue mailing list: clue at cluedenver.org
> For information, account preferences, or to unsubscribe see:
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20130625/10254b2f/attachment-0001.html
More information about the clue
mailing list