# Reloading shell environment

**URL:** <https://discourse.chef.io/t/reloading-shell-environment/4202>\
**Category:** Chef Infra (archive)\
**Created:** [July 4, 2013, 9:20am UTC](https://discourse.chef.io/t/reloading-shell-environment/4202 "2013-07-04T09:20:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ian\_Chilton](https://avatars.discourse-cdn.com/v4/letter/i/97f17d/32.png) [@Ian\_Chilton](https://discourse.chef.io/u/Ian_Chilton)\
**Post date:** [July 4, 2013, 9:20am UTC](https://discourse.chef.io/t/reloading-shell-environment/4202/1 "2013-07-04T09:20:00Z")

</div>

Hi,

I have a chef wrapper cookbook & recipe setup that’s provisioning our whole  
development environment.

What I want to do though is also include the currently manual steps of  
setting up the application at the end:

- Clone from private Github repo
- Drop in database.yml
- gem update --system
- gem install bundler
- bundle install

What I need to do though is:

a) Get access to the private github repo

b) Execute as the correct user, as on vagrant it will be vagrant and on  
normal installs it might be something else - and if chef is invoked  
manually it will be running from the user with sudo or if it’s invoked by  
vagrant, it’s run as root.

c) Load chruby into the environment so all the gem stuff is done under the  
correct Ruby.

How do others handle these issues?

I’m thinking that getting access to the private repo could be done using  
deploy keys included with the chef repo which gives read only access to  
that single repo.

I’m thinking the target user could be by way of a node attribute (and could  
check for the presence of a vagrant user to set the default).

The environment thing I guess I could go through the chruby script and see  
what environment variables it sets and set ENV[‘PATH’], ENV[‘GEM\_HOME’] etc  
etc, but that’s ugly and prone to breakage in the future.

Interested in advice or to hear from anyone who’s been here before and has  
stuff executing under certain rubies which were setup earlier in the  
provision.

Thanks,

Ian

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [July 8, 2013, 4:01pm UTC](https://discourse.chef.io/t/reloading-shell-environment/4202/2 "2013-07-08T16:01:21Z")

</div>

On Thursday, July 4, 2013 at 2:20 AM, Ian Chilton wrote:

> Hi,
> 
> I have a chef wrapper cookbook & recipe setup that's provisioning our whole development environment.
> 
> What I want to do though is also include the currently manual steps of setting up the application at the end:
> 
> - Clone from private Github repo
> - Drop in database.yml
> - gem update --system
> - gem install bundler
> - bundle install
> 
> What I need to do though is:
> 
> a) Get access to the private github repo
> 
> b) Execute as the correct user, as on vagrant it will be vagrant and on normal installs it might be something else - and if chef is invoked manually it will be running from the user with sudo or if it's invoked by vagrant, it's run as root.
> 
> c) Load chruby into the environment so all the gem stuff is done under the correct Ruby.
> 
> How do others handle these issues?
> 
> I'm thinking that getting access to the private repo could be done using deploy keys included with the chef repo which gives read only access to that single repo.
> 
> I'm thinking the target user could be by way of a node attribute (and could check for the presence of a vagrant user to set the default).
> 
> The environment thing I guess I could go through the chruby script and see what environment variables it sets and set ENV['PATH'], ENV['GEM\_HOME'] etc etc, but that's ugly and prone to breakage in the future.
> 
> Interested in advice or to hear from anyone who's been here before and has stuff executing under certain rubies which were setup earlier in the provision.
> 
> Thanks,
> 
> Ian

Adding a `--login` flag to the bash resource will handle sourcing rc scripts as described in the "invocation" section of the bash man page.

--  
Daniel DeLeo