Opened 12 years ago

Closed 7 years ago

#227 closed defect (wontfix)

IZ1476: Error from "settings.sh" when set -u is set

Reported by: coffman Owned by:
Priority: highest Milestone:
Component: sge Version: 6.0
Severity: minor Keywords: HP install
Cc:

Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1476]

        Issue #:      1476             Platform:     HP       Reporter: coffman (coffman)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     dom
          URL:
       * Summary:     Error from "settings.sh" when set -u is set
   Status whiteboard:
      Attachments:

     Issue 1476 blocks:
   Votes for issue 1476:


   Opened: Wed Mar 2 12:47:00 -0700 2005 
------------------------


When a user has set -u set in their environment
with SHLIB_PATH not set and they run the
util/arch, an error

SHLIB_PATH: parameter not set

To prevent this error message on hpux, the
variable should be tested before referenced...

   ------- Additional comments from andy Thu Mar 3 05:11:17 -0700 2005 -------
Changing "summary", "OS" and "version" and "subcomponent". Problem
occurs in 5.3 and 6.0 as well.

This is not a HPUX only problem, nor a problem of SGE_ROOT/util/arch.

The problem occurs when in the user shell "-u" is set ("set -u") and
the "settings.sh" file is sourced, e.g. on Solaris the error messages
is similar:

$  $SGE_ROOT/util/arch
sol-sparc64
$  $SGE_ROOT/util/arch -lib
LD_LIBRARY_PATH
$  . $SGE_ROOT/default/common/settings.sh
LD_LIBRARY_PATH: parameter not set


The scripts are designed that the default behavior of the Bourne shell
(no errror when unset variables are used) is implicitely used. Since
the "settings.sh" file is sourced (and not called) there can be a
conflict with the current user settings.

The solution would be to check if the variable is set (like in
"settings.csh").

Adding a line "set +u" is not an option since it would affect the
current shell behavior due to the sourcing if "settings.sh"


Workaround: "set +u" before sourcing the settings.sh file.


Change History (1)

comment:1 Changed 7 years ago by dlove

  • Priority set to highest
  • Resolution set to wontfix
  • Severity set to minor
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.