[clue] env variables

Tue Jun 25 09:29:04 MDT 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20130625/b73b5fc6/attachment-0001.html 