Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28384 Discussions

/bin/sh: ifort not found; executing a script as root

pacobraxe
Beginner
1,258 Views
Hi all,

I am trying to install an application (from source) using a given script (Makefile) and I'd like to use ifort as the fortran compiler. I included ifort_vars in .bashrc (for bash shell) and .profile (for sh shell). The problem is that the script calls /bin/sh in a non-interactive shell, so .profile is not loaded at the beginning and thus ifort_vars is never visited. The result I get is "ifort not found".

This problem can be solved when the script is called as user. The solution is to call ifort_vars inside .shinit and define in .profile:

ENV=/home/user/.shinit; export ENV

Unfortunately this solution does not work when make has to be executed as root (that is my case). Besides, I cannot change /bin/sh by /bin/bash inside the script, because other parts of the script will not work.

Any idea?

Thanks,
Paco
0 Kudos
1 Solution
TimP
Honored Contributor III
1,258 Views
You appear to be confirming that your system runs a pure sh as root. So, you would have to avoid the attempt to use the "." abbreviation, which works only in bash. It would not be surprising if your system required root to set up PATH explicitly, as a security precaution, for example by typing in the source ifortvars for each session. If you had a higher level of security for root, such as SELINUX, it could be practically impossible to run ifort as root, an act which most people would consider inadvisable anyway. I don't see how it could be useful to discuss that further here.

View solution in original post

0 Kudos
4 Replies
TimP
Honored Contributor III
1,258 Views
Unless someone understands you better, this leaves us guessing.
The ifortvars script is not "include"d, it is "source"d.
Under sh, "source" can't be abbreviated as "." as it can under bash.
0 Kudos
pacobraxe
Beginner
1,258 Views
Quoting - tim18
Unless someone understands you better, this leaves us guessing.
The ifortvars script is not "include"d, it is "source"d.
Under sh, "source" can't be abbreviated as "." as it can under bash.
:-) Sorry, my hability to express myself using English is very poor!

What I mean by "include" is just what you say: use "source" in bash and "." in sh. The problem is that the init files .bashrc / .profile are visited (or executed) by the corresponding shell only at the beginnig of a interactive shell, I mean, when the shell will let introduce by keyboard some commands. When you write #/bin/sh at the beginning of a script, that opens a non-interactive shell and, at least in the case of sh, .profile is not visited (or readed, executed...).

When you are logged as user, that can be solved writing in ENV variable the path to the file that you can executed when a non-interactive shell starts (.shinit, in my previous post). The problem is that I do know how to do the same when I am logged as root. I need to be root to execute the script since it has to create some directories in /opt.

Sorry again if my explanation is confusing or wrong,

Paco
0 Kudos
TimP
Honored Contributor III
1,259 Views
You appear to be confirming that your system runs a pure sh as root. So, you would have to avoid the attempt to use the "." abbreviation, which works only in bash. It would not be surprising if your system required root to set up PATH explicitly, as a security precaution, for example by typing in the source ifortvars for each session. If you had a higher level of security for root, such as SELINUX, it could be practically impossible to run ifort as root, an act which most people would consider inadvisable anyway. I don't see how it could be useful to discuss that further here.
0 Kudos
pacobraxe
Beginner
1,258 Views
Quoting - tim18
You appear to be confirming that your system runs a pure sh as root. So, you would have to avoid the attempt to use the "." abbreviation, which works only in bash. It would not be surprising if your system required root to set up PATH explicitly, as a security precaution, for example by typing in the source ifortvars for each session. If you had a higher level of security for root, such as SELINUX, it could be practically impossible to run ifort as root, an act which most people would consider inadvisable anyway. I don't see how it could be useful to discuss that further here.

My system is ubuntu 9.04 and yes, by default, sh is a pure sh. Following your recommendations I did:

* login as root: sudo su -
* execute the file where ifort_vars is called: . .shinit
* call the script: make

It works!

The content of .shinit is:
INCLUDE=/opt/intel/Compiler/11.1/056/mkl/include:${INCLUDE}; export INCLUDE
. /opt/intel/Compiler/11.1/056/bin/intel64/ifortvars_intel64.sh intel64
. /opt/intel/Compiler/11.1/056/bin/intel64/idbvars.sh intel64

Thank you for your help,
Paco
0 Kudos
Reply