Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: $PATH setting not being used ??

  1. #1
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default $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).

    Code:
    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)

  2. #2
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default Re: $PATH setting not being used ??

    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?

  3. #3

    Default Re: $PATH setting not being used ??

    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 I don't even know if they still include it or not.

  4. #4
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default Re: $PATH setting not being used ??

    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!!!!!!!!!!!!!!!!!!!!!!!!!!

  5. #5
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default Re: $PATH setting not being used ??

    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")

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,005

    Default Re: $PATH setting not being used ??

    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.
    Henk van Velden

  7. #7

    Default Re: $PATH setting not being used ??

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

  8. #8
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default Re: $PATH setting not being used ??

    Thanks for the explanation. 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

  9. #9
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,175

    Default Re: $PATH setting not being used ??

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

  10. #10
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,005

    Default Re: $PATH setting not being used ??

    Quote Originally Posted by PattiMichelle View Post
    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
    Code:
    #!/bin/ksh
    then instead
    Code:
    /bin/ksh lalala
    is started.
    Henk van Velden

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •