Hard-coded paths

Very good question. I’d like to know as well.

We have Cloverleaf on HP-UX and I really like to use symbolic links for this problem.

When we started with CL3.7.1,  $HCIROOT was /hci/cloverleaf3.7.1 in which all sites resided. Our main site was called ‘orbis’. We created a symbolic link /cldata, which refered to /hci/cloverleaf3.7.1/orbis. In our Netconfig, all paths concerning the orbis-site start with /cldata.

Later we migrated to CL5.2 with $HCIROOT /hci/qdx5.2/integrator. All we had to do is make sure all subdirectories of our orbis site were in place and then recreate the /cldata symbolic link so it referred to /hci/qdx5.2/integrator/orbis.

This way we don’t need to change all paths in our Netconfig.

I teach this in all my classes!

NEVER use hard-coded paths to files or directories under the Cloverleaf root.  This can be a very insiduous error as the paths will work until you delete the old version of Cloverleaf.

There are several methods:

1. Use relative paths since you know the working directory is the process directory.  For example, to access the file named data.txt in the site directory:  set path ../../../data.txt.

2.  Use the environment variables like HCIROOT/HCISITEDIR  which are available via the global env array or the supplied global variables like HciRoot and HciSiteDir.  For example to access a file named names.csv which is placed in a directory under the root named LOOKUPS:

(I prefer to use the file join command)

set path [file join $HciRoot LOOKUPS names.csv]

3.  You can really simplify by placing the files or directories directly under the process directory then all you need is the file or directory name.

Robert.

I wrote a simple perl script as part of our migration from 3.5.5 -> 5.1 and this changed the hard coded lines to relative for paths and icons etc.

With all this discussion, I decided to test something out.  I created a link /hci/qdxroot to point to /hci/qdx5.4.1/integrator.  I went into the first line of tcl scripts and replaced #!/hci/qdx5.4.1/integrator/bin/hcitcl with #!/hci/qdxroot/bin/hcitcl  .  The scripts ran as before.  With this success, I then decided to change all scripts that use setroot.  For the first parameter, I changed /hci/qdx5.4.1/integrator to /hci/qdxroot  .  However, the scripts get a DBI error when trying to access the recovery database.   From the command line, I get a 944 synchronization error.  Is the path to the recovery database hardcoded either in the recovery database itself or the vista.taf file?

I was wondering the same thing…

Kevin:

simply change the first line toL #!/usr/bin/env tcl  or #!/usr/bin/env perl

You will never have to change again

Recently installed version 5.8 on a server that had 5.6 on it.  We promoted one site to 5.8 .   So, which version of TCL does /usr/bin/env tcl point to ?  Version associated with 5.6 or associated with 5.8?

We installed Cloverleaf 5.8 on a clean server and are using both 5.8 and 5.6.  Based on the response from entering “puts $tcl_version” within hcitcl, both versions use Tcl/Tk 8.4.