elg@killer.UUCP (Eric Green) (05/08/88)
System: AT&T 3b2, running Sys V.3
Software: Jove 4.9, as recently posted to comp.unix.sources
symptoms: will not find files in the home directory, if currently
located in some other directory. This includes the .joverc file,
which is a real pain.
problem: The PWD environment variable is read to find out what
the current working directory is. Unfortunately, the version of csh
that I am using does not maintain the PWD environment variable. Since csh was
entered in my home directory, the PWD environment variable remains as such,
and the pr_name routine chops off the first part of the filename thinking
we're already in that directory.
solution: find some other way of finding the current working directory, under
Sys V with non-standard shells. Or, remove the dir stack code from Jove --
which is likely to have rippling side effects that I shudder to think of.
Problem: How CAN I find that directory, to replace the getenv("PWD") currently
used? Or is it a lost cause with csh?
--
Eric Lee Green elg@usl.CSNET Snail Mail P.O. Box 92191
ihnp4!killer!elg Lafayette, LA 70509
"Is a dream a lie that don't come true, or is it something worse?"gerry@syntron.UUCP (G. Roderick Singleton) (05/11/88)
In article <4022@killer.UUCP> elg@killer.UUCP (Eric Green) writes:
<System: AT&T 3b2, running Sys V.3
<Software: Jove 4.9, as recently posted to comp.unix.sources
<
<symptoms: will not find files in the home directory, if currently
<located in some other directory. This includes the .joverc file,
<which is a real pain.
<
<problem: The PWD environment variable is read to find out what
<the current working directory is. Unfortunately, the version of csh
<that I am using does not maintain the PWD environment variable. Since csh was
<entered in my home directory, the PWD environment variable remains as such,
<and the pr_name routine chops off the first part of the filename thinking
<we're already in that directory.
<
<solution: find some other way of finding the current working directory, under
<Sys V with non-standard shells. Or, remove the dir stack code from Jove --
<which is likely to have rippling side effects that I shudder to think of.
<
<Problem: How CAN I find that directory, to replace the getenv("PWD") currently
<used? Or is it a lost cause with csh?
<
Hmm, I'm a recent convert to csh and I have a question, however dumb,
that may be pertinent to the problem. WHere do you set your
envinronment variables, in .cshrc or .login?
Since I'm new, it took a lot of experiments before I discovered that
.cshrc is executed every time a new csh is forked and I suspect that
this is what you are missing.
If this assumption is out to lunch, please email your corrections. If not
I hope it helps you Eric and saves the hours needed to munge the sources.
gerry
--
G. Roderick Singleton, gerry@{ suncan | geac | eclectic | syntron }.UUCP
"ALL animals are created equal, BUT some animals are MORE equal than others."
George Orwellelg@killer.UUCP (Eric Green) (05/13/88)
> In article <4022@killer.UUCP> elg@killer.UUCP (Eric Green) writes: > <System: AT&T 3b2, running Sys V.3 > <Software: Jove 4.9, as recently posted to comp.unix.sources > <problem: The PWD environment variable is read to find out what > <the current working directory is. Unfortunately, the version of csh > <that I am using does not maintain the PWD environment variable. Since csh was I "solved" the problem simply by commenting out the getenv("CWD") and getenv("PWD") calls, and falling through into the getcwd() call. But that's no permenant solution. Perhaps we need an #ifdef NOENV or something like that (gawd, yet another variable in tune.h!). It's not a bug in csh. csh doesn't need fixing (though Sys V does :-). csh isn't supposed to maintain the "PWD" environment variable. If csh was my login shell, that would be no problem -- there would be no "PWD" environment variable, and Jove would fall through into the getcwd(). Unfortunately, I am constrained by events beyond my control to log in using sh or ksh as my initial login shell -- which creates a PWD environment variable, which is passed to csh, which is passed to Jove, which does the wrong thing. Perhaps this cute attempt to be efficient should be excised completely from the Jove code? Too bad I can't reach jpayne (unless he didn't graduate, after all -- last I heard, he should be walking down that aisle in Rochester, funny cap on head, tripping over a silly gown). --- Eric Lee Green {cuae2,ihnp4}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie that don't come true, or is it something worse?"
wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (05/17/88)
[ Summary of the bug - if the PWD variable is present, Jove 4.9 assumes [ that ksh is keeping it up to date, and uses it instead of getcwd(). [ This is a problem if you aren't using ksh, but have PWD in your [ environment from a parent process, because it's presumably wrong. In article <4071@killer.UUCP> elg@killer.UUCP (Eric Green) writes: } I "solved" the problem simply by commenting out the getenv("CWD") and } getenv("PWD") calls, and falling through into the getcwd() call. But } that's no permanent solution. [..] } It's not a bug in csh. csh doesn't need fixing (though Sys V does :-). csh } isn't supposed to maintain the "PWD" environment variable. If csh was my } login shell, that would be no problem -- there would be no "PWD" environment } variable, and Jove would fall through into the getcwd(). If you think ksh maintaining $PWD is a bug, better excise $cwd from csh :-). As a workaround, in your .login (if applicable) or .cshrc, do unsetenv PWD setenv SHELL=/bin/csh ## whatever the syntax is? The general problem is how to detect when an environment variable has a reliable meaning - at minimum, you should only use $PWD if it's non-null and $SHELL is ksh, but even that's unreliable. Better to just let Jove getcwd(). In a shell script, you can distinguish between Bourne sh and ksh reliably by checking if [ "$RANDOM" = "$RANDOM" ] but that's no help from an executable. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # skep2 is a local machine I'm trying to turn into a server. Please send # mail to ho95c or ho95e instead. Thanks.
michaelk@copper.TEK.COM (Michael D. Kersenbrock) (05/18/88)
To "fix" Jove under csh, put these in csh's `.cshrc' file (modify as appropriate for your purposes). CWD is now "supported" (these are from my .cshrc). alias cd 'cd \!*; setenv CWD $cwd' alias pd 'pushd \!*; setenv CWD $cwd' alias ppd 'echo "pd $cwd" > ~/.poplast ; popd \!*; setenv CWD $cwd' alias unppd 'source ~/.poplast' -- Mike Kersenbrock Tektronix Microcomputer Development Products Aloha, Oregon
sjoerd@cs.vu.nl (Sjoerd Mullender) (05/18/88)
In article <4022@killer.UUCP> elg@killer.UUCP (Eric Green) writes: [ describes that Jove 4.9 believes the value of the PWD environment variable ] In article <4071@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >I "solved" the problem simply by commenting out the getenv("CWD") and >getenv("PWD") calls, and falling through into the getcwd() call. But that's no >permenant solution. Perhaps we need an #ifdef NOENV or something like that >(gawd, yet another variable in tune.h!). A better solution would be to check the value returned by getenv("CWD") or getenv("PWD"). This is very easily done as follows: You stat the result of the getenv() call. If stat fails then the value was wrong and you call getcwd(). If the stat succeeds you also stat ".". Then you compare the device and the inode values in both stat structures to see if they are the same. If not, call getcwd(). If they *are* the same then $CWD/$PWD pointed to the current directory (posibly via symbolic links, but that isn't too bad). If $CWD/$PWD is correct this will cost 2 extra calls to stat(). Not a very large performance penalty. > Eric Lee Green {cuae2,ihnp4}!killer!elg > Snail Mail P.O. Box 92191 Lafayette, LA 70509 -- Sjoerd Mullender sjoerd@cs.vu.nl When this doesn't work try sending via uunet.uu.net or mcvax.uucp.
keith@mit-vax.LCS.MIT.EDU (Keith Packard) (05/18/88)
In article <4022@killer.UUCP> elg@killer.UUCP (Eric Green) writes: <System: AT&T 3b2, running Sys V.3 <Software: Jove 4.9, as recently posted to comp.unix.sources <problem: The PWD environment variable is read to find out what <the current working directory is. Unfortunately, the version of csh <that I am using does not maintain the PWD environment variable. Since csh was Here's a more reasonable solution -- a replacement for getCWD that make's sure it knows where it is. This is actually from version 4.7 of Jove -- I'm currently negotiating with jonathan about incorporating some of the changes I've made back into the regular distribution, but haven't started looking at what will be needed to merge with 4.9. keith packard keith@expo.lcs.mit.edu getCWD() { char *cwd; #ifdef IPROCS #ifdef SYSVR2 extern char *getcwd(); #else extern char *getwd(); #endif char pathname[FILESIZE]; #endif struct stat dots, cwds; if ((cwd = getenv("PWD")) || (cwd = getenv ("CWD"))) { if (stat (".", &dots) == -1 || stat (cwd, &cwds) == -1 || cwds.st_ino != dots.st_ino || cwds.st_dev != dots.st_dev) cwd = 0; } if (cwd == 0) #ifdef IPROCS # ifdef SYSVR2 cwd = getcwd(pathname, sizeof (pathname)); # else cwd = getwd(pathname); # endif #else cwd = getwd(); #endif setCWD(cwd); }