How to source ~/.profile through a script with effects lasting after the script has run? - maemo.org

Active Topics

[M7] [Announce] HP41cx (0)
to Applications by Halftux - 10 hrs, 51 mins ago
Camera phone competition March 2023 "Endless" (21)
to General by Maemish - 1 day, 9 hrs ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (9)
to SailfishOS by biketool - 3 days, 13 hrs ago
more...

Page 1 of 2

Next >

Thread Tools

白い熊	2011-09-01 , 14:07
Posts: 451 \| Thanked: 334 times \| Joined on Sep 2009	#1

I have customized PATH, CFLAGS, etc many variables in .profile, which get changed dynamically upon copying files to certain directories.

After I do this, to make the system aware, I source ~/.profile again, which makes it reread these dirs.

I've been busting my brains, how to call:

Code:

. ~/.profile

from a shell script and have the exported environment variables stay in the system, after this shellscript has run. Can anyone help me?

What I mean is, for instance: say .profile reads ~/bin for subdirs and then adds these to the PATH

So I source it now, it only has one subdir, so only ~/bin/1 gets added to the PATH

Let's say I create ~/bin/2, and now I need to source ~/.profile to add ~/bin/1 and ~/bin/2 to PATH

If I open a terminal and run

Code:

. ~/.profile

all's fine and the PATH contains the proper dirs.

But if I create a shell script with just

Code:

. ~/.profile

and then run

Code:

./shellscript.sh

the PATH gets exported within the script, but once it finishes running the PATH in the term is obviously not affected by the export.

I want to source .profile in a shellscript somehow and have the resultant exported variables remain exported after the shellscript has finished running.

Can I do this somehow? Can't figure out how...

Thanks for advice.

Quote & Reply |

Rob1n	2011-09-01 , 14:22
Posts: 3,617 \| Thanked: 2,412 times \| Joined on Nov 2009 @ Cambridge, UK	#2

You need to call ". ./shellscript.sh", otherwise you're starting a separate shell to run it in, so all variables are lost afterwards.

Quote & Reply |

白い熊	2011-09-01 , 14:29
Posts: 451 \| Thanked: 334 times \| Joined on Sep 2009	#3

Yeah, but that's exactly the thing, that's not solving anything, there's no difference between sourcing .profile and shellscript.sh

I cannot source anything, I can just call a script.

That's because I need to incorporate the sourcing into other scripts which manipulate these files based on criteria etc. and then after all is done the variables should be sourced in the system. That's why I can't source the master shellscript, because I call it to do some dynamic operations, give it parameters of directories to create etc. and then when it's done, I need .profile or any file to automatically be sourced and variables exported.

Quote & Reply |

lidow	2011-09-01 , 15:08
Posts: 151 \| Thanked: 93 times \| Joined on Sep 2009 @ sofia, bulgaria	#4

put

exec bash

at the end of your shell script. This will open a shell with already exported environment.

Quote & Reply |

Joorin	2011-09-01 , 19:09
Posts: 726 \| Thanked: 345 times \| Joined on Apr 2010 @ Sweden	#5

Environment variables are, by definition, bound to a certain process.

If you spawn a child process, it inherits the environment.

So, if you want your changes to stay available you need to run the process in the same environment as the one you changed.

Quote & Reply |

白い熊	2011-09-01 , 19:36
Posts: 451 \| Thanked: 334 times \| Joined on Sep 2009	#6

Originally Posted by lidow

at the end of your shell script. This will open a shell with already exported environment.

I need the changes to stay active in the current shell, not a new instance...

Quote & Reply |

白い熊	2011-09-01 , 19:40
Posts: 451 \| Thanked: 334 times \| Joined on Sep 2009	#7

Originally Posted by Joorin

Environment variables are, by definition, bound to a certain process.

If you spawn a child process, it inherits the environment.

So, if you want your changes to stay available you need to run the process in the same environment as the one you changed.

I understand the logic, however I keep thinking there has to be a way to accomplish via a shell script the same effect in the current terminal that is achieved via sourcing a file, without having to source the top calling file.

Why I don't want to source the file is simple: I want the whole procedure to be callable via a command, that I can put in the path, so that the user doesn't have to worry about sourcing something.

But I want to be able to change the environment variables for the given shell environment and all the future spawned processes dynamically.

I keep thinking this has to be doable somehow...

Quote & Reply |

Joorin	2011-09-01 , 20:48
Posts: 726 \| Thanked: 345 times \| Joined on Apr 2010 @ Sweden	#8

Code:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

extern char **environ;

int main() {
  printf("environ[0]: %s\n", environ[0]);

  printf("PATH: %s\n", getenv("PATH"));

  if(!setenv("PATH", "/my/new/path", 1)) {
    printf("PATH: %s\n", getenv("PATH"));
  } else {
    printf("Could not change PATH variable!\n");
  }

  return 0;
}

Quote & Reply |

The Following User Says Thank You to Joorin For This Useful Post:
白い熊

白い熊	2011-09-02 , 05:27
Posts: 451 \| Thanked: 334 times \| Joined on Sep 2009	#9

Same thing though. Compile and run in a terminal, while it's running it changes it. Once command finishes, the old PATH is in effect.

I'm trying to change the PATH and other variables in a running shell via a command callable in a script, that would have a permanent effect.

Quote & Reply |

lidow	2011-09-02 , 06:19
Posts: 151 \| Thanked: 93 times \| Joined on Sep 2009 @ sofia, bulgaria	#10

From exec manpage:

The exec() family of functions replaces the current process image with a new process image.

exec script.sh

where in script.sh you source environment and then exec bash, will substitute your current shell with the one from the script. This will give you all environments you need, and will not open chain of subshells.