2

I have an application which modifies environment variables. The intent is to launch a bash shell with a modified context-specific environment.

When my application modifies the environment, and exec()s "bash --noprofile --norc" with the modified environment then I almost get the behavior I want, except that aliases are dropped. If I log in and open a shell directly from the OS, I get the "normal" aliases, but if my application launches a bash, then I don't get any aliases because the initialization files are skipped.

Is there any way to have bash initialize from a dynamic source? In other words, it would be helpful if I could have my application launch "bash" with all its various user/facility settings (including aliases) and then at the end of that, source the differences that my application needs to apply. Ideally, this would leave open a shell prepped and ready to go for my users. I'm not finding this (or perhaps understanding it) from the man page.

In an ideal world, we could refactor the user/factory settings to be more reentrant (aware of the application, and skip reinitialization steps that don't need to happen again); but in practice this is turning out to be a little bit of a hassle.

Any suggestions? Thanks.

  • What application is this? – Braiam Aug 18 '14 at 21:33
  • I don't understand: why do you run bash --noprofile --norc and not bash if the intent is to run bash with the user's favorite aliases and other customization? – Gilles Aug 18 '14 at 21:53
  • bash allows you to export functions via the environment, using export -f. I don't know how these are actually represented in the environment array -- you could try looking at the bash source to see how it does it. – Barmar Aug 18 '14 at 22:15
0
bash --noprofile --norc <<ALIAS
$(alias)
exec </dev/tty
ALIAS

That should do it if you're running the bash --noprofile... bit from a bash that knows your aliases.

Else you could do as @WilliamEverett suggests (which, as I believe, is ultimately the better way to go). One way to facilitate this is:

alias >~/.aliasrc
{   cp ~/.bashrc ~/.bashrc.old
    grep -v '^ *alias' <~/.bashrc.old
    echo '. ~/.aliasrc'
} >~/.bashrc

You'll want to do a little comparison between the rc file that generates and the .old one it saves in case some alias definitions were multi-lined. After you've sorted that though you can:

bash --noprofile --rcfile ~/.aliasrc
  • I mark this as the correct answer, because I can derive a solution from this: essentially I need to run "bash << ALIAS" and have my application then pipe in all the environment settings that it has customized. As mikeserv presented, it isn't exactly what I'm looking for, but it gave me the means to a solution. – Mayur Patel Aug 19 '14 at 12:59
  • @MayurPatel - you may want to have a look at this. Another way to do the thing is: echo 'eval "$@"' |bash --noprofile --norc -si -- '$command_that_outputs_env' "$(alias)" 'exec </dev/tty' – mikeserv Aug 19 '14 at 13:09
1

You could make your .bashrc more modular (for example by sourcing a .aliasrc with your aliases) and then have your custom environment only source the modules that you specify for that environment.

  • In my 4th paragraph, I tried to indicate that this approach is turning out to be a little bit of a hassle. Ideally, everything could be broken out into digestible pieces. – Mayur Patel Aug 19 '14 at 12:55
0

You could put

if [ -f ~/.Mayur_Patel_special ]
then
    . ~/.Mayur_Patel_special
    rm ~/.Mayur_Patel_special
fi

at the end of your .bashrc, and then have your application create that file.  And, obviously, run bash without the --noprofile and --norc options.  If there might be multiple instances of this running concurrently, make the filename unique; for example, by incorporating a PID.

  • Since he uses --norc, his .bashrc won't be run. – Barmar Aug 18 '14 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.