A coworker of mine has written a csh script that starts with #!/usr/bin/csh -f. It's my understanding that the -f should skip the .cshrc and .login files, but here's the problem: In the script "line" is used, and I happen to have a "line" in my ~/bin. When the script is ran my ~/bin is still in the path and the script does not work.
Why is ~/bin in my path if csh was instructed not to load the .cshrc and .login files?
I ran a test by renmaing my ".cshrc" file and logging in. When doing so echo $PATH only gave me "/usr/bin:", so it seems the .cshrc is being used.
#! /usr/bin/csh -f
works for me on solaris. I created a .cshrc with "echo in .cshrc" and wrote a two line csh script with a similiar echo. Without the -f, I get both echo's. Put the -f back in, I get one echo. You must be invoking the script wrong... see: [thread=7077]What does "#! /usr/bin/ksh" mean?[/thread]
Thanks for the reply, and sorry for the delay: I was on vacation. Here is some more information:
There is also a "b" switch, but this shouldn't affect the "f"? ("-fb")
The script is called from a third-party application; how it does it, I'm not sure. I imagine this could be a factor, but how can one call a shell script without honoring the switches?
Looking again at your first post, you tested that renaming .cshrc had the expected effect while logging in. Which proves nothing at all with respect to the third party script. Why not rename your .cshrc, then try that third party script? It may not be running your .cshrc at all. Maybe your bin directory is already in your PATH. If so, refraining from running your .cshrc again will avoid putting a second copy of your bin directory in your PATH. But that will not magicly remove a copy already there. This is why Bill Joy split out .login from .cshrc. You should not fiddle with your environment every time you run a script.