Path: utzoo!attcan!uunet!steinmetz!vdsvax!barnett
From: barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
Newsgroups: comp.unix.questions
Subject: Re: A csh question ...
Keywords: csh question .login .cshrc
Message-ID: <4434@vdsvax.steinmetz.ge.com>
Date: 23 May 88 03:43:02 GMT
References: <636@fxgrp.UUCP> <3990@csli.STANFORD.EDU> <655@fxgrp.UUCP>
Reply-To: barnett@steinmetz.ge.com (Bruce G. Barnett)
Organization: General Electric CRD, Schenectady, NY
Lines: 61

In article <655@fxgrp.UUCP> ljz%fx.com@ames.arc.nasa.gov (Lloyd Zusman) writes:

|I tend to use very few 'set' variables, because I wish to avoid the
|overhead of sourcing a .cshrc with lots of commands.  I almost always
|write my csh scripts with the first line set to "#!/bin/csh -f" so that
|they will start up quickly.  For these two reasons, among others, I
|tend to use lots of environment variables.

You are trying to avoid extra overhead, but i believe you are doing it
the wrong way. See below.

|But I'd
|like to know if there's something I'm missing that would explain why
|csh was designed to do it the way it does?

Usually people start up special applications in their .login file.
Emacs, X windows, suntools, ... In fact, when you want the user to 
run a special application, you just modify the .login file. Yet
anything in the .cshrc file is also executed.

There are also times when you may want to allow a remote shell or copy, but
no local login. Because .cshrc is sourced before .login, this is
possible. You can have remote users/scripts that only run non-interactive, etc.

But let's not start anything religious.

If I understand what you want to do, I suggest you make use of
site specific .cshrc files. e.g.

	if ( -e .my-cshrc && -o .my-cshrc ) source .my-cshrc

Yes, this does mean you have to maintain an extra file.
But you probably have to maintain some site dependancies somewhere.
Use m4(1) or make(1) if you wish.

I believe this will be much more efficient that what you are doing
for the following reasons:

	1. Sticking extra baggage in your environment variables
	   means that each process has to copy the entire environment
	   variable list for EACH PROCESS. This slows down each fork.
	   Not just scripts.

	2. Testing for the existance of a file should be faster than
	   executing a program. (Okay, if all of your systems use the
	   same NFS home directory, this wouldn't win. The file would
	   always be there.)

	3. Enclosing large lists of aliases in if/then blocks
	   still requires the shell to scan past them even if they
	   aren't going to use them. That is, the construct

		if ( $?prompt ) then
			# monster list of aliases
			...
		endif 
	
	   is inefficient if the shell is not interactive.
-- 
	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
				uunet!steinmetz!barnett