Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then 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.
If A.sh EXPORTS the changes as necessary to the appropriate environment variables, and/or updates the linkers' search locations by means of `ldconfig` then the changes would be effected from that point onward.
Perhaps providing specifics about what you are trying to accomplish would get you a more concise answer.
If an environment variable is changed inside a script (which in effect starts a new shell) the parent shell doesn't know about the change.
Likewise, a script that calls another shell wont know about the environment variables of that shell. If an environment variable is set (and exported) the only things that know about the value are the current shell itself and processes that shell forks, not the parent shell.
The LD_LIBRARY_PATH variable is set when the shell is started, it doesn't constantly get reset. If in your example, a.sh resets the library path with ldconfig, then I don't even think that it (a.sh) will know about the change (although next time the script is run, it will know about any prior changes). In that example, however, b.sh SHOULD know about the change as it is being started AFTER the library path is modified.
You may be able to reload things with "exec bash" after a script changes the global systems settings, I'm not sure (and I don't have a system I can test it with).
This is interesting; I may stand corrected by Forrestt, though I too am inclined to test this out.
I thought environment variables were global variables, taking effect globally and universally under normal circumstances?
If not, then it would be safe to assume (until learned otherwise) that if a shell environment variable is set and exported from within a shell/script, that very shell/script does not know about it? Doesn't really make sense, but again, I will test this out.
So shell # 1 did not pick up the change to the variable made in a.sh (shell # 2).
I stand corrected, and wiser
I did not go to the extent of changing around my library paths to test ldconfig. Perhaps the OP can tell us what happens?
Perhaps also a workaround for the OP would be to have main.sh in two or more parts:
main.sh does its thing, then calls a.sh which changes some variables. a.sh THEN does not return to the original main.sh, but instead executes for example main2.sh, which will be aware of the variables and work accordingly? And so on...
Thanks for enlightening us Forrestt!
Last edited by GrapefruiTgirl; 06-09-2008 at 02:53 PM.
Reason: Learned otherwise :)
Yes, but the variable didn't get updated. This is because the exit 0 was exiting from the new shell that was executed at the top of a.sh, not the shell that was calling it in main.sh, and like we said before, changes to an environment variable can only be seen by the current shell or child processes.
The "." is basically saying, "don't start a new shell, just run the commands found in this file from this shell". It's sort of like an include in other languages. Without the "." you are starting a new shell (as noted by the first line of the script).
#!/bin/bash <-- This says start a new bash shell, but is a comment if called with the "."
When it gets to the "exit 0" it is running that command as if it were part of the main.sh script and dutifully exits.
I didn't mean to imply that you couldn't have an "exit 0" inside a sub-script, only that you couldn't have an "exit 0" inside a sub-script if you want to use the "." shell call.