$PATH setting not being used ??

I’m really confused by this one! I set the PATH statement to include the bin directory for an openmpi build, but the system doesn’t seem to be using it. I noticed a “.” in there, and don’t know how that got there… but why isn’t it finding this app in the path? If I give the absolute path, it works as it should. The only way I could get mpif90 to work without giving the full path is to create an alias. I was told prepending the path was the way to get other builds of executables such as OpenMPI to be chosen by the OS, but it’s not working here (doesn’t seem to work for any of the openmpi apps).

wrf@VBOS-e:~> csh
Setting up for WRFDA
Done setting up for WRFDA
wrf@VBOS-e-> mpif90
mpif90: Command not found.
wrf@VBOS-e-> /usr/local/openmpi16/bin/mpif90
gfortran: fatal error: no input files
compilation terminated.
wrf@VBOS-e-> echo $PATH
/usr/local/openmpi16/lib:/usr/local/openmpi16/lib64:/usr/local/openmpi16/bin:.:/home/wrf/00_GCMs/EMS/wrfems/strc:/home/wrf/00_GCMs/EMS/wrfems/strc/ems_bin:/home/wrf/00_GCMs/EMS/wrfems/domwiz/bin:/home/wrf/00_GCMs/EMS/wrfems/bin:/home/wrf/00_GCMs/EMS/wrfems/util/grads/bin:/home/wrf/00_GCMs/EMS/wrfems/util/bin:/home/wrf/00_GCMs/EMS/wrfems/util/grads/data:/home/wrf/00_GCMs/EMS/wrfems/util/ncarg/bin:/home/wrf/00_GCMs/EMS/wrfems/util/mpich2/bin:.:/home/wrf/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/bin/X11:/bin:/usr/sbin:/sbin:/etc:/home/wrf/00_GCMs/EMS/wrfems/util/nawips/os/linux/bin:/home/wrf/00_GCMs/EMS/wrfems/util/nawips/bin
wrf@VBOS-e-> /usr/local/openmpi16/bin/mpif90
gfortran: fatal error: no input files
compilation terminated.
wrf@VBOS-e-> mpif90
mpif90: Command not found.
wrf@VBOS-e-> 

Here’s how I set the path (in a shell script sourced from .cshrc):

#!/bin/csh -f
set path = (/usr/local/openmpi16/bin $PATH)
set path = (/usr/local/openmpi16/lib64 $PATH)
set path = (/usr/local/openmpi16/lib $PATH)

ATTEMPTED EDIT: OK, I kind of found a workaround - set the path in bash then csh picks it up. But what am I doing wrong in my csh shell script? It’s actually setting the path, but the system isn’t using it.

Yet Another Edit: OK, the “-f” at the start of my script seemed to be the problem. But why did $PATH show up correctly yet the system not appear use it when I tried to call mpif90?

I come more from a bash background… but maybe a setenv in lieu of set… ie: setenv PATH /usr/local/openmpi16/bin:$PATH

OpenMPI, hey? CooI… what are you using it for? Iwrote up the SCTP BTL for OpenMPI back when I was in school :smiley: I don’t even know if they still include it or not.

What the heck??? Somehow I’m completely borking the path!

wrf@VBOS-e-> ls
ls: Command not found.
wrf@VBOS-e->

EDIT: OK - don’t tell me - it’s a caps issue, right? In bash it’s $PATH but in csh it’s $path - right? Does csh even use $PATH?
Does $LD_LIBRARY_PATH simply map to $ld_library_path under csh?

THANKS!!!

OK, so I think I get it. PATH in bash => path in csh because it’s a “system thing” and LD_LIBRARY_PATH in bash => LD_LIBRARY_PATH in csh because it’s a “gfortran thing” (an “application”)

This is not about “the system does (not) use it”. PATH or any other prcocess environmment variable belongs to a process. And it is up to the executable that runs in that process to use a specific variable, interprete it and act accordingly. Thus when you use PATH in *bash, *look in bash documentation what bash uses it for.

And you look in the csh documentation if it uses a variable PATH at all, and what it does with it (it’s use in csh can be completely different from that in bash or* ksh*). And when you look in csh for a similar functionality as PATH is to *bash, *you have to browse the csh documentation.

Thus it is NOT the system (what you ever do mean with that, the kernel?), but the idividual programs that know about environment variables. And any similar usage of the same named variable accros different programs is only a question of standardisation/comon practise. I think of DISPLAY in most GUI applications (easy to do for them because they mostly use the same library routines that implement it). And of course PATH and many more in the Bourne Shell, the Korn shell, the POSIX shell and the Borne Again Shell. But the C-shell is allways a bit diifferent) different. That is why some people like the C-shell, but then you must read docs of it.

should be uppercase PATH placed in: ~/.login i believe. does that not work for you?

Thanks for the explanation.:slight_smile: Some of these weather/climate codes I’m building come right out and say, “this code expects csh” and some codes don’t, so I look for hints, like seeing a “setenv” suggestion (by the code’s docs) suggests csh, but “export” suggests bash. Some docs are kind enough to we non-experts to give both. Some codes don’t come out and actually tell you - so it gets kinda tricky. It seems like when I’ve seen “setenv” suggestions in the docs, they usually go along with suggestions to prepend certain directories into the “path” (i.e., instead of PATH). But when I see instructions for bash, it’s in caps (like PATH and LD_LIBRARY_PATH). I guess these are shell-specific conventions (caps or not). Unfortunately, I learned linux starting with a GUI so I’m kinda lean on these kinds of command line underpinnings. Live and learn and thank GOD for user forums and the very kind, supportive folks who are selflessly on here!!! Patricia

I just learned that the !# at the beginning of a script can tell which shell it’s expecting! (like #!/bin/tcsh)

The first line starting with #! (called the “shebang”) is a must. It makes a script a script. Else it is only a bunch of statements. And it is not about expecting someting. It tells what interpreter should be used to interprete the script. When you write a script in language A (say Perl), you do not want it interpreted by interpreter B (say the C-shell). Thus it is very, very important.

In short and loosely, when an executable is started by the kernel (is made to run as a process) and it starts wiith a shebang (thus not being a binary executable), the interpreter is started instead and the script given to it as the first parameter field.

Example: when the executable lalala is started and the first line is

#!/bin/ksh

then instead

/bin/ksh lalala

is started.

Not to be confused with “shubang”! :wink:

Well, I tried all sh?bang in Wikipedia. shabang redirects to shebang. All the others, including shubang, fail to produce a real Wikipedia page (all in the English Wikipedia, not in the Banglish part).

Bangerdebangbang-bang-bang.

On 08/01/12 08:46, hcvv pecked at the keyboard and wrote:
> please_try_again;2477648 Wrote:
>> Not to be confused with “shubang”! :wink:
> Well, I tried all sh?bang in Wikipedia. shabang redirects to shebang.
> All the others, including shubang, fail to produce a real Wikipedia page
> (all in the English Wikipedia, not in the Banglish part).
>
> Bangerdebangbang-bang-bang.
>
>
The explanation under shebang seems to provide what you are looking for.
Did you actually read it?

Huh? Who is the “you” here you are addressing?

Well it sounds like you’re well underway… awesome. I think you’ll appreciate the command line, once some of the voodoo magic fizzles away :smiley:

Apparently not everything is in Wikipedia yet. This](http://membres.multimania.fr/p0ke/images/choubang.JPG) is a shubang, also written shu-bang or choubang. But people normally don’t write it. Totally out of topic here! Sorry. I was just kidding (and assuming that every Dutchman would know that). And it’s different from a shebang (or sha-bang), although after using the former (shu-bang) for a too long period of time, you might not be able to tell which is what or pronounce it correctly. lol!

On Wed, 01 Aug 2012 12:46:04 GMT, hcvv <hcvv@no-mx.forums.opensuse.org>
wrote:

>
>please_try_again;2477648 Wrote:
>> Not to be confused with “shubang”! :wink:
>Well, I tried all sh?bang in Wikipedia. shabang redirects to shebang.
>All the others, including shubang, fail to produce a real Wikipedia page
>(all in the English Wikipedia, not in the Banglish part).
>
>Bangerdebangbang-bang-bang.

Say, are you making bangers and mash?

?-)

On 2012-08-01 09:36, hcvv wrote:
> In short and loosely, when an executable is started by the kernel (is
> made to run as a process) and it starts wiith a shebang (thus not being
> a binary executable), the interpreter is started instead and the script
> given to it as the first parameter field.

And you can add parameters to the shebang line.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Thanks, Henk! The things you learn on this forum!! rotfl!

banglish - I like it :slight_smile: