Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I think that if you call a script it is executed in its own subshell that doesn't give variables and such stuff to the shell you called it from. You can set it in another way by sourcing the script, there are probably other ways I don't know about
. skyeye1 # dot space at the beginning of line
Indeed. When any program is launched, including your script, it gets a copy of the environment of the "parent process" (=running program). The program in question can then change it's own environment any way it likes, but the changes will not affect the parent. When you use "export", like in your script, the changed environment variable will however be carried on to the children of your script (=the programs & scripts that are called in your script).
So, in short, when your script ends, it's environment settings are cleaned up and the changes you tried to make are thus lost.
Sourcing can indeed be a solution. "Sourcing", either via
actually takes the code of your_script.sh and runs it in the current environment, rather than creating a new environment.
export a library path in a shell script does not work
I thought that it would be better to continue this thread rather than creating a new one so, I am trying to set the library path as my program needs the MKL library routines. although this has worked in another system, in the current one it gives me an error and it is not very obvious why
thank you for your reply, finally i did set the path to point to the non standard location, but i realised that this was not the issue.
the program compiled properly but i kept getting the segmentation fault error 174, in a discussion with the system supervisor, he told me that gfortran and intel libraries are getting mixed up for some reason and although i use ifort and have the proper paths pointed when it runs it switches and searches for gfortran standard libraries for some reason, this is not an issue of the paths anymore. something is getting mixed up and the declaration e.g. real*8:: A(length) has to be written as real*8,dimension(length):: A so i do not get the error( f90 f77 difference or something like that). eventually when it reaches the e.g. dpotri routine it gives me again the 174 error and i cannot do anything about it as it is a routine i use from the library and it should be working but it does not. the same program in another system compiles and runs properly. probably something is not set properly in the system. thank you for your reply