Question

I have created a tcsh shell script as follows:

#!/bin/tcsh

setenv PATH  ""
setenv PATH  .:$HOME/bin:/usr/sbin:/usr/bin:/bin:/usr/X11R6/bin:/usr/local/cuda/bin:/usr/local/bin:/usr/bin:$PATH

setenv LD_LIBRARY_PATH ""
setenv LD_LIBRARY_PATH .:/usr/local/cuda/lib:/usr/local/cuda/lib64/:/usr/local/cuda:/usr/lib:/usr/lib32:/usr/local/cuda/bin:/usr/local/lib/:${LD_LIBRARY_PATH}

Then I have made this script executable and when I try to execute it as

./script.sh, it gives following errors:

script.sh: 3: setenv: not found

script.sh: 4: setenv: not found

script.sh: 6: setenv: not found

script.sh: 7: setenv: not found

Any pointers, how to set these paths in my shell script?

Answer 1

I don’t get the same error on my system.

UPDATE : See the last two paragraphs for my best guess about what’s going on.

My initial best guess was that you can fix the problem by changing shebang

#!/bin/tcsh

to

#!/bin/tcsh -f

(Or use

#!/bin/csh -f

The features that tcsh adds to the original csh are mostly useful for interactive use rather than scripting.)

The -f option tells tcsh not to process your .login and .cshrc or .tcshrc files when it starts up. Generally you don’t want a script to do this; it makes the script’s behavior dependent on your own environment setup. Perhaps you have something in your .login that does something odd with setenv, though I can’t think of what it might be. Try adding the -f and see if that helps. Even if it doesn’t, you should do that anyway.

(And don’t use -f for /bin/sh or /bin/bash scripts; it means something else, and isn’t needed.)

Some other observations:

Setting $PATH and $LD_LIBRARY_PATH to the empty string is useless. Just delete those two lines.

EDIT :

On re-reading your question, I see what you’re doing there. You set $PATH to the empty string, and then prepend more text to it:

setenv PATH ""
setenv PATH this:that:$PATH

That makes more sense than I thought it did, but it’s still simpler to write one command:

setenv PATH this:that

Putting . in your $PATH, especially at the beginning, is a bad idea. Think about what happens if your run the script in a directory where someone has deposited a command name ls that does something nasty. If you want to execute a command in the current directory, use ./command. (Putting . at the end of $PATH is safer, but still not a very good idea.)

(And using tcsh or csh as a scripting language (as opposed to an interactive shell) is widely considered to be a bad idea as well. This article, even if it doesn’t persuade you to give up on tcsh scripting, will at least make you aware of the pitfalls.)

Oh, and if it’s a tcsh script, why do you call it script.sh? Suffixes on file names aren’t required under Unix-like systems (unlike Windows), but usually a .sh suffix implies that it’s a Bourne shell script. Call it script.tcsh, or script.csh, or just script.

EDIT :

Taking a closer look at the error message you’re getting, it looks like the errors are coming from /bin/sh, not from tcsh.

On my system, when I change setenv to Setenv (a nonexistent command), running the script with tcsh gives me:

Setenv: Command not found.
Setenv: Command not found.
Setenv: Command not found.
Setenv: Command not found.

which doesn’t match the error messages you showed us. When I run it explicitly as /bin/sh foo.tcsh (leaving the setenv commands alone), I get:

foo.tcsh: 3: setenv: not found
foo.tcsh: 4: setenv: not found
foo.tcsh: 6: setenv: not found
foo.tcsh: 7: setenv: not found

which does match the format of the errors you got.

You say that /bin/tcsh --version gives correct results, so that’s not the problem. Somehow the script is being executed by /bin/sh, not by tcsh.

Here’s my best guess about what’s going on. You’re running on Cygwin, or maybe MSYS, but you’re invoking your script from a cmd shell, not from a Cygwin shell. Your Windows system has been configured to recognize a .sh suffix to indicate that the file is a script to be executed by C:\cygwin\bin\sh.exe (as I mentioned before, file suffixes don’t usually matter on Unix, or in the Cygwin environment, but they do on Windows).

The simplest solution would probably be to rewrite the script to conform to Bourne shell syntax. But there should be ways to cause Windows to invoke Cygwin’s tcsh to execute it. If I’ve guess right, let us know and we can probably come up with a solution.