When/how is $HOSTNAME populated ?

UNIX AIX
1

When and how is the variable $HOSTNAME populated ?

I am asking because I had a weird situation that just happened.

I have created backup scripts that do backups on different servers. Each servers has different folders to be backed up. So I had included a check on $HOSTNAME to find out which folders to back up.

But tonight, when I started the backup on one server, the backup did not start because it said I was on the wrong server (my coding). I turned out aht the content of the $HOSTNAME was empty. All the other servers had no problems starting the same exact backup script as it $HOSTNAME was containing the right servename.

Here are the steps I did immediatlly after:
A) Checking the content of the $HOSTNAME variable:

  • I logged with my own operator userid and did "echo $HOSTNAME". It had the servername in it
  • I did a "sudo echo $HOSTNAME" and the content was empty
  • I did a "sudo su -" then a "echo $HOSTNAME and the variable had the server name in it.
    B) I opened up another window and did the same steps as in A) and all 3 steps showed that $HOSTNAME had a servername content.

I had to resort doing a "sudo su -" and start the backup. Otherwise, I would have had to change the script as a quick workaround.

Somehow, on that specific xterm window I had opened, the content of the $HOSTNAME variable was not populated in all cases. I want to know how this happened and why as it may happen again with another operator (they don't know how to script).

2

Any variable in the shell comes into existence by your shell's startup scripts...

I would start there. Not sure about ksh, but in bash it would be /etc/bashrc....start there, and that file should lead you to other files that might get "sourced" (processed) within that file. Then there is your local user shell startup file....for instance, "~/.bashrc"

If you know the files, you could "grep -n HOSTNAME" on those files, to show the line numbers where the string HOSTNAME occurs.

3

I don't know what happened but maybe an alternative might be to use in your script:

MY_HOSTNAME=`hostname`

#or

MY_HOSTNAME=`uname -n`

Might be more safe instead of hoping that $HOSTNAME is set.

4

I would use $(hostname) instead of $HOSTNAME

I have systems too where $HOSTNAME is not set, but the hostname command works always

5

funksen and zaxxon are both correct. Never depend on any variables set outside of a script but "bring with you what you need to work with".

The number 1 problem (by a large margin) with cron-scripts is: "i have written a script which ran fine in my shell, then i put it into crontab and now it doesn't work any more. It still runs when i test it." The reason is that your login shell inherits all kinds of environment variables but scripts started by cron don't. If you implicitly rely on - for instance - $PATH being set the same way it is set in your interactive shell you are in for a bad surprise.

Several variables are set in your "~/.profile" and in your "~/.kshrc", but some system-wide variables are set in "/etc/environment". All these files do NOT apply to scripts started by cron.

This is the reason why i have ALL my scripts use their own environment, regardless of them being run in cron or not. The beginning of my scripts always looks like this:

#! /bin/ksh

if [ -z "$DEVELOP" ] ; then                      # set environment
     . /usr/local/lib/ksh/f_env
else
     . ~/lib/f_env
fi

typeset SCRIPT_INTERN_VAR1=""
typeset SCRIPT_INTERN_VAR2=""

... etc., etc. ...

where "/usr/local/lib/ksh/f_env" is a ksh function which declares all the variables common to all the scripts. It looks like this:

     unset ENV                                   # clear the environment

     #---------------------------------------------------- set basic environment

     typeset -x OS=$(uname -a | cut -d' ' -f1)   # find out the OS
                                                 # read in standard environment
     case "$OS" in
          AIX)
               . /etc/environment
               ;;

          Linux)
               . /etc/profile
               ;;

          *)
               . /etc/environment
               ;;
     esac

                                                 # set default TERM variable
     case "$OS" in
          AIX)
               TERMDEF="$(termdef)"
               ;;

          Linux)
               TERMDEF="$TERM"
               ;;

          *)
               TERMDEF="$TERM"
               ;;

     esac
     typeset -x TERM=${TERMDEF:-'wyse60'}        # set default TERM variable
     typeset -x LANG=C                           # default language environment
     typeset -x EDITOR=vi                        # what else ? ;-))
     typeset -x VISUAL=$EDITOR

     typeset -x PATH="/usr/bin"                  # set the path
                PATH="$PATH:/bin"
                PATH="$PATH:/etc"
                PATH="$PATH:/usr/sbin"
                PATH="$PATH:/usr/ucb"
                PATH="$PATH:/sbin"
                PATH="$PATH:/usr/bin/X11"
                PATH="$PATH:/usr/local/bin"      # tools, home for scripts
                PATH="$PATH:/usr/local/sbin"     # -"-

     typeset -x chTmpDir=""                      # path for temporary files

... etc., etc. ...

I never have to worry about a script being run in cron or not, being run by a specific user or even on a specific system - it won't fail because of the environment being set wrongly.

I hope this helps.

bakunin

6

Maybe it's a question of the shell you're using? Some shells use $HOST (eg. tcsh) others (eg. bash) use $HOSTNAME

mbs