Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!agate!bionet!csd4.milw.wisc.edu!uwmcsd1!marque!uunet!mcvax!unido!tub!uwbln!ckl
From: ckl@uwbln.UUCP (Christoph Kuenkel)
Newsgroups: comp.unix.wizards
Subject: Re: Set parent env with csh script
Message-ID: <1291@uwbull.uwbln.UUCP>
Date: 9 Jan 89 19:22:47 GMT
References: <174@v7fs1.UUCP> <9314@smoke.BRL.MIL>
Distribution: world,comp
Organization: UniWare GmbH, Berlin
Lines: 28

In article <9314@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:

> [...]
> SOURCING a shell script (as opposed to EXECUTING it) causes the
> changes to occur in the invoking shell context (as opposed to
> a subprocess context).  Thus you can alter environment variable
> via a sourced script that does setenv (or Bourne shell equivalent).

Unfortunately, csh doesn't get it right since it does not evaluate $path
to lookup the file to be sourced (at least on my SysV based system).
Therefore, the location of the script is not transparent to the user as it
is in the case of an executed shell script.  
Bourne shell does it right, but attention, in

	while <expr>; do
		<stmnt>
	done <io redirection>

<stmnt> is executed in a ``subrocess context'' due to the io redirection!
So any variable assignement and/or environment setting is uneffective outside
the while-loop.
Any elegant solution to that?

christoph
-- 
# include <std/disclaimer.h>
Christoph Kuenkel/UniWare GmbH       Kantstr. 152, 1000 Berlin 12, West Germany
ck@tub.BITNET                ckl@uwbln             {unido,tmpmbx,tub}!uwbln!ckl