Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: CLASSPATH scripts do not work as defined in Getting Started in
 Derby Guide
From: "John Storta Jr." <js@storta.net>
To: derby-user@db.apache.org
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 31 Dec 2009 18:03:02 -0500
Message-ID: <1262300582.3083.33.camel@aragorn>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

I have just started working with Derby.  I was going through the getting
started guide and came across an issue.

On pages 13 and 14 of the 'Getting Started in Derby Guide', there are 3
scripts referenced that can be used to set the CLASSPATH environment
variable.  setEmbeddedCP, setNetworkServerCP, & setNetworkClientCP.  The
documentation indicates that the appropriate script should be run
depending on your needs.

Running the scripts like any other script does not work.

When a script is run, it launches a new shell for that script.  The
CLASSPATH is set within that shell.  Once the script is complete, that
shell exits and you are returned to your shell.  The CLASSPATH is only
changed for the shell that the script was running in.  The CLASSPATH in
your shell is unchanged.

$ ${DERBY_HOME}/bin/setNetworkClientCP
Will result in your CLASSPATH being unchanged.

In order for CLASSPATH in your shell to be updated, you have to run the
script from within your shell (not launch a new shell).  This is done by
'sourcing' the script.

$ . ${DERBY_HOME}/bin/setNetworkClientCP
Will run the script within your shell resulting in your CLASSPATH being
updated.

The documentation is not clear on this.

Updating the documentation to state that the scripts should be sourced
rather than run will introduce another problem.  The scripts contain
error checks which will exit the shell if DERBY_HOME is not set.  If you
source the script, it is running in your shell, which means your shell
will exit if the error is encountered. 

The documentation should be updated and the scripts would need to be
updated to spit out the error, but not exit the shell.

I looked through JIRA and I do not see this logged as a bug.  If there
is agreement that this is a bug, I can open one.  As I am new to this, I
wanted to bounce it off the list first.


John S.