setting "set +u"

[Shivkumar]

Hi,

i was checking an installation document and it says that
on HP-UX, Prior to the software ( that particular software) installation, check your .profile file for a set +u option. If it has a set -u option, do a set +u to nullify it. A setting of set -u will cause a problem when the installation sets a SHLIB_PATH for user "abc" (here application would be installed and run by "abc" user).

My confusion is:
if set -u has already been set then can i remove it ?

why i need to keep both in the .profile as below:

set -u
set +u

Thanks,
Shiv

[Steven E. Protter · Accepted solution]

Shalom Shiv,

Take these items out of your /etc/profile and .profile and any profiles that get called.

Then log a user on.

set

See what the settings are.

I don't recall this being a required setting, so you just need to thoroughly go through your profile source scripts and figure out where it is being set.

Eliminating all entries to this effect should get rid of the problem.

A word of caution, if this was added to profiles, there may be an application that needs it. It could be it was just configured in to an abnormalplace and effects too many users.

Its possible that cleaning this out of your profiles will break an application or service.

SEP

[A. Clay Stephenson]

It's very common to have opposite setting inside .profile or a shell script. The idea is that you might set +u at one point so that unset variables do not cause an error. You then execute a few statements and then do a set -u so that unset variables are considered an error.

Without seeing your entire .profile it's not possible to say if this is good or bad.

[Geoff Wild]

Sounds like the doc is telling you to do a set +u prior to installing the software (if there is a set -u in the .profile) - else, no need to worry about it.

No need to add it to the .profile either way....

Rgds...Geoff

[Victor BERRIDGE]

Hi Shiv,

Well look at root default .profile, you will see both...
# Example assumes /home/root exists.
set +u

PATH=/usr/sbin:$PATH:/sbin:/home/$LOGNAME

# Be sure that VUE does not invoke tty commands

etc....
then
# Set up shell environment:

set -u # error if undefined variable.
trap "echo 'logout root'" 0 # what to do on exit.

MANPATH=$MANPATH:/opt/contrib/man:/opt/contrib/man/%L:.

etc...


...

Why do you have set -u?
-u Treat unset parameters as an error when substituting.

You do want to know when you have unset parameters, no?
...



All the best
Victor

[Geoff Wild]

Run a set -o

By default,
nounset on

set +u will turn it off - then set -u to turn it back on...

Rgds...Geoff

[Chan 007]

Shiv,

This is required only during you one off installation.

If you set it now. Complete the installation and logoff.

So go as per the document and complete. Once you logout, the set will go..!

Once again if you login that parameter will go.

Chan

[Bill Hassell]

The installation document is telling you that due to novice script writing techniques, there may be commands that refer to undefined variables and rather than properly handle the situation, it will be ignored. Arrgghhhh!!

set -u is the first step is writing a production script. An undefined varaible is often a mispelled name and you WANT the script to stop. For example:

set +u
MYTEMP=tmp/mystuff
echo rm -rf /$MYTMP

Now DO NOT try the above commands!! The last statement will remove every file and directory in the entire computer. (I put echo in front of it to show what command will be, which is "rm -rf /" An undefined variable is a timebomb, waiting to destroy things.

If you change the set +u to set -u, the script will stop before running the rm command and state that $MYTMP is undefined (notice the spelling error?)

I always make sure set -u is in /etc/profile as well as .profile for all users. You should ask the vendor why such unstable code is being used, and what's wrong with adding set +u to the beginning of their script. There is no excuse to put the entire system at risk by removing a safety element.

[Shivkumar]

In the .profile i also saw the below line:-

# Set up the search paths:
PATH=$PATH:.

This PATH is inherited from which user or place ?

[Shivkumar]

In the .profile i also saw the below line:-

# Set up the search paths:
PATH=$PATH:.

This PATH is inherited from which user or place ? and i know . stands for current directory. But in this scenario what it (dot) signifies ?

[James R. Ferguson]

Hi Shiv:

With regard to the PATH variable, for the Posix shell, the login process first reads '/etc/profile' and then the '.profile'.

If you examine '/etc/profile' you will see that the PATH is setup there. Normally this is based on '/etc/PATH'.

Very often, additional directories are added to '/etc/PATH' as a consequence of running a 'swinstall' sesssion to install a new product.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Shiv:

I see you posted a second question while I answered the first. You asked what the dot in the PATH statement signifies, as in:

PATH=$PATH:.

As you concluded, this appends the current directory to the PATH variable. Remember, the colon is the delimiter between paths.

It is a security hole to add this to root's profile. To do so allows a piece of code to be deposited anywhere for potential execution by the unwary. Without it, as root, you have to specifically write:

./file_to_execute

...instead of simply:

file_to_execute

...when you have moved (cd'ed) into a directory. You see this difference when running as root as opposed to running as a non-root user. The idea is that as root, you want to be very sure what it is you are executing. Adding "." to your PATH lessens the explicit knowledge you have.

Regards!

...JRF...

[Nguyen Anh Tien]

The POSIX/Korn Shell will generate error messages when referencing a variable that
has not been defined and the set -u option is set. You can enter set -o to view the
options configured for your shell. If -u is not set, no error will be generated, and the
variable value will be substituted with NULL. You can disable this option with: set +u.
See the man page sh-posix(1) for more details.
HTH
tienna

[Cem Tugrul]

Hi Shiv,

As an additon the other replies i think
you need such a kind of link which explains
unix fundemental
Good Luck,

http://docs.hp.com/en/B2355-90046/index.html

[Muthukumar_5]

set -u is used to denote error for unused variables.

Difference is simple:

# set -u
# echo $Muthu
sh: Muthu: Parameter not set.
#
# set +u
# echo $Muthu

#

It will be silent when set +u.

set -u and set +u is giving opposite mearning.

set -u

set +u
will be worth. Else it is not needed.

--
Muthu

[Muthukumar_5]

If you are having PATH variable as,

PATH=$PATH:.

then search path will include PWD too. It is useful always.

You are not needed to use ./<scriptname> to execute.

Example:

# cat > muthu.ksh
echo "hi ok"
# chmod u+x muthu.ksh
# ./muthu.ksh
hi ok
# export PATH=$PATH:.
# muthu.ksh
hi ok

--
Muthu

[Muthukumar_5]

Another importan feature with,

PATH=$PATH:.

is need to include . for inclusion of SHELL variables or contents to a script.

Example:

Without that setting:

# cat test1.ksh
echo "hi"
VAR="Muthu"
# cat test2.ksh
. test1.ksh
echo $VAR
# ./test2.ksh
Muthu

# export PATH=$PATH:.
# cat test2.ksh
test1.ksh
echo $VAR
# test2.ksh
Muthu

It is enough.

--
Muthu

[Geoff Wild]

Having . in your PATH is very dangerous...

Consider a malicious user - writes a script, and calls it say: who

In the script he puts:

#!/bin/sh
cp ./passwd /etc/passwd
/usr/bin/who $1


And in his passwd file he has himself with uid 0

Wow - you just gave him root....

Rgds...Geoff

[Steven E. Protter]

Shiv,

It might be a good idea to run security hardening on these machines.

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B6849AA

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=PERL

Some of of the things you have posted here and in other threads point out the need for perhaps a few courses at your local HP educational center.

http://education.hp.com

I'd recommend Sysadmin 1 & 2, Network & System Security, Internet Security and System troubleshooting. I still have the manuals for those classes and the experience of working side by side with an HP instructor who has years of experience doing real world systems administration would be very helpful.

The root .profile or /etc/profile warns never put a dot at the beginning or anywhere in root's path.

Over the years developers have taken a lot of time to improve documentation. My boss likes to say RTFM. A little reading can clarify things a great deal.

SEP

[Shivkumar]

Hi Steven; what is the full form of "RTFM" ?

Regards,
Shiv

[Arunvijai_4]

Hi Shiv,

It is "Read The Fine Manual" or
"Read The F***ing Manual"

-Arun

[Arunvijai_4]

Hi Shiv, A Wikipedia link,

http://en.wikipedia.org/wiki/RTFM

http://catb.org/~esr/jargon/html/R/RTFM.html

-Arun

[Shivkumar]

Under what circumstances do we need to set SHLIB_PATH ? Do we set in /etc/profile or user's .profile ?

What is the syntax for setting this environment variable ?

Regards,
Shiv

[Arunvijai_4]

Hi Shiv,

You asked, Under what circumstances do we need to set SHLIB_PATH ? Do we set in /etc/profile or user's .profile ?

SHLIB_PATH is Shared library path where OS search for shared libraries with .sl (11.11) .so (11.23) extensions.

When loader loads an executable, it searches the required .sl or .so in SHLIB_PATH.

-Arun

[Arunvijai_4]

Hi Shiv,

Use the chatr command to determine if SHLIB_PATH is "disabled" for the program you are using.

The following examples show the chatr command being used for program /opt/java1.4/bin/java:

chatr /opt/java1.4/bin/java

To ensure your program uses SHLIB_PATH, issue the following command:

chatr +s enable /opt/java1.4/bin/java

Ensure the SHLIB_PATH is defined in your environment and includes the /usr/lib directory (echo $SHLIB_PATH). To define the path, issue:

export SHLIB_PATH=$SHLIB_PATH:/usr/lib

-Arun