[comp.unix.questions] Using ".." in Scripts & Makefiles

marko@hutch (Mark O'Shea) (03/27/91)

I am resposible for upgrading a set of test suites which have some scripts
and makefiles that do things like:

   HOME=..

or
   cd ../../

etc.

Now I know that they will work, but I am instinctively uncomfortable with
them.  I personally believe that spelling out the path names is a better
practice.

What I want to know is some good reasons to change to what I believe to
be a sounder way of doing it, eg,

  HOME=/<name>/<user>/<etc>

or
  cd /<name>/<dir1>/<etc>

The folks I am presently working for don't agree with me on this point.

Thanks,
Mark O'Shea
marko@ijf1.intel.com

hunt@dg-rtp.rtp.dg.com (Greg Hunt) (03/28/91)

In article <1991Mar26.201509.5048@intelhf.hf.intel.com>, marko@hutch (Mark O'Shea) writes:
> I am resposible for upgrading a set of test suites which have some scripts
> and makefiles that do things like:
> 
>    HOME=..
> 
> or
>    cd ../../
> 
> etc.
> 
> Now I know that they will work, but I am instinctively uncomfortable with
> them.  I personally believe that spelling out the path names is a better
> practice.
> 
> What I want to know is some good reasons to change to what I believe to
> be a sounder way of doing it, eg,
> 
>   HOME=/<name>/<user>/<etc>
> 
> or
>   cd /<name>/<dir1>/<etc>
> 
> The folks I am presently working for don't agree with me on this point.

If the test suite is designed to be used by anyone or may be installed
on any of your machines, assuming you have more than one, then I'd say
the relative pathnames are much better.  The reasons I've used relative
pathnames in test scripts that I've written are these:

1.  It allows you to load the test suite anywhere in the filesystem.
    This means that you're not relying on any particular directories
    or usernames existing at the time you load the package, which
    gives you greater flexibility.  Hard coded pathnames will really
    bit you when you try to move the test to another machine, or
    if they rely on other files that happen to live in the directory
    that you load the test into.  Fixing up the suite to run in each
    place you load it can be quite frustrating.

2.  It allows you to have multiple copies of the test suite on the
    same system in different directories, and the copies won't
    interfere with each other.  This lets multiple people run the
    tests at the same time, and also allows you to be modifying and
    testing the suite at the same time someone else is running another
    copy elsewhere on the system.

I would change the HOME, however, to something like SUITE_DIR like
this:

    SUITE_DIR=`pwd`

I would dump the suite to tape from above the directory, so that when
you reload it, you get a directory, and then everything loads into
that directory or directories below it.  I'd also make the test only
write to SUITE_DIR or directories below it (or places like /tmp).  Make
the tests as self contained as possible so that all you have to do is
load the tape, maybe run some setup scripts, and then run the tests.
The more you can automate, the fewer problems will happen when other
people try to run the tests.

That's my opinion.  I'd suggest sitting down with the folks that will
be running the tests and see exactly what they want, and build them
as flexibility as possible to meet their needs.  Remember that the
folks running the tests may not know as much about them as you do since
you're the one that wrote them.  Making it easier for them to run them
will mean fewer hassles for you when they try.  Good luck!

-- 
Greg Hunt                        Internet: hunt@dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.

jik@athena.mit.edu (Jonathan I. Kamens) (03/28/91)

  I agree with the people with whom you work.  I see no reason not to
use ".." in a Makefile, if your Makefile knows the structure of the
tree in which it is being compiled.  Furthermore, if you tar up the
entire source tree and move it to another location, then absolute
paths in Makefiles may fail, while relative paths will not.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

jpm@logixwi.uucp (Jan-Piet Mens @ Logix GmbH, Wiesbaden) (03/28/91)

In article <1991Mar26.201509.5048@intelhf.hf.intel.com> marko@hutch (Mark O'Shea) writes:
>I am resposible for upgrading a set of test suites which have some scripts
>and makefiles that do things like:
>   HOME=..
>or
>   cd ../../
>
>etc.
>
>Now I know that they will work, but I am instinctively uncomfortable with
>them.  I personally believe that spelling out the path names is a better
>practice.
>

I don't agree. I also (if I must do it) use the '..' business. 
If you have to move the base directory of your package to somewhere 
else in the file-system, you will have to modify all the absolute 
pathnames !!!.

Why not use -I.. for includes for example, or define absolute pathnames
in Makefiles, etc.

Regards,
	JP

-- 
Jan-Piet Mens, Logix GmbH				    jpm@logixwi.UUCP
Moritzstr. 50, D-6200 Wiesbaden            ...!uunet!mcsun!unido!logixwi!jpm