AstroCaribe dotFiles Project


“And what, pray tell, is a dotFiles Project?”

This is just a fancy name, a title, if you will, to describe how I set up my terminal for development, particularly useful after a fresh system reinstall. Simply put, these files dictate and orchestrate any startup actions that I wish to take when I start my terminal. Many devs and coders have their own versions of their dotFiles, and this blog post is no different. Please feel free to research the topic, and mix and match to suit your needs.

This is a minimal post, intended mostly as a reminder to myself on rebuilding my environment in the event of a system refresh. There are sample files that can be viewed on Bitbucket, and should serve as examples of how I’m using my dotFiles. A later post will detail my strategy for setting up a new environment, which rely on this dotFile setup.

Disclaimer: Every system is different, this by no means is guaranteed to work for everyone in every situation. As far as I know, this should apply to Unix-based systems (Mac OS X and Ubuntu, I’m looking at you!). The only thing I can say with certainty is that this will not work on a Windows system.

For reference, the name of the dot file is echoed at the end of every file; this is a self-reminder as to what runs when:
Screen Shot 2015-12-09 at 22.08.16.png

Below are brief descriptions of each dotFile and what it does:


This script is intended to house operations that you’d typically like to start only once, at the start of a new terminal session. You can also add additional tasks here that are supportive of a ‘refresh’ of sorts; re-sourcing other dot files to add additional behaviour/characteristics without shutting down/restarting your current terminal session.

One example of operations that can/should be done in here are alterations to your prompt via $PS1 variable. Change the prompt at will, and reload by executing:

$> refresh


P.S. – ‘refresh’ is an alias that I wrote to do above task:

# Refresh shell
alias refresh=’source ~/.bashrc’



This script is intended to house user-defined aliases, and nothing else! This scripts can be rerun directly, or via the ‘refresh’ alias defined therein. For example, you can add new aliases and activate them by executing the following:

$> refresh

No need to start a new terminal session!



This script is intended to launch only when a new terminal is open. Currently, it’s only purpose is to launch the .profile script.

Some programs installed via Homebrew (and possibly others) install to .profile instead of .bash_profile. However, (if I remember right), a new terminal session will launch a .bash_profile script first. In this case, this script will launch the .profile script. This helps me avoid having to cut/paste code placed in .profile to .bash_profile.



This script is intended to run only once, at the start of a new terminal session. You would not typically want to run this more than once per session; for that functionality, add to the .bashrc file instead!

This script houses everything you would need to do to set up a terminal environment; the contents of this script are not intended to be run more than once in a terminal session. For example, executing:

export PATH=/usr/local/bin:$PATH

will cause /usr/local/bin to be added to the $PATH variable everytime it is executed. This particular example will probably not break anything, but will make for an unusually long and ugly $PATH environmental variable.

Future Additions

In the future, a few more dot files may be included in this repo as needed. I should not go too crazy here, so that I can keep track of the different dotfiles needed to edit for a particular task. See below for more vague details!


This script will house custom functions that will be needed by the terminal for various functions.


This one will house path setup, to remove them from .profile and make it leaner.


Any suggestions for additional ones? Comment below!



SendGrid Template Transfer Ruby Script

Currently, there is not an easy option for transferring templates within SendGrid from one account to another; say, from a development account to a production. While trying to execute this for my current job, I could not find a solution that was already created for this very purpose.

However, SendGrid does provide a Template API for this very purpose. This particular solution is for Ruby, but I’m sure other languages can be supported as well. I plan to create a Python solution script for this as well in my free time, so look out for this in the future!I wrote this to save others the pain of doing this from scratch; I do hope that you find this useful! Below I outline the transfer flow, with includedside notes of discoveries I made along the way. Enjoy!


Please refer to the script repo on specifics for configuration.

Script Flow

This script was born out of the lack of resources on how to transfer templates between accounts, using the supplied SendGrid Template API and corresponding Template Versions documentation for transferring multiple versions of a template.

Note: This solution was coded in Ruby 2.1.2; to code in another language, use this flow as a guide, and code against appropriate analogs.

Important Caveat: Currently, this script *does not** selectively copy templates. This script will copy ALL of the templates from the first account.*

With that out of the way, here’s the current flow, all examples within are drawn from the Template API docs:

Step 1. Retrieve all available templates from Account1

In this step, all templates are copied from the first account (the transfer from account). This operation does not copy the template content; only the identifying information is retrieved:

  "templates": [
      "id": "e8ac01d5-a07a-4a71-b14c-4721136fe6aa",
      "name": "example template name",
      "versions": [
          "id": "5997fcf6-2b9f-484d-acd5-7e9a99f0dc1f",
          "template_id": "9c59c1fb-931a-40fc-a658-50f871f3e41c",
          "active": 1,
          "name": "example version name",
          "updated_at": "2014-03-19 18:56:33"

Template versions are also retrieved, but still no template content.

As such, the approach here is to retrieve all the templates, and store the main :id and :name of each in an array in memory. A sample Curl example to the API looks like this:

curl -X GET

Step 2. Recursively retrieve each template from Account1

Using the stored array in memory, each template is then retrieved using :id;

curl -X GET

This operation now retrieves the information of interest needed to transfer the templates intact to the receiving account:

  "templates": [
      "id": "e8ac01d5-a07a-4a71-b14c-4721136fe6aa",
      "name": "example template name",
      "versions": [
          "id": "de37d11b-082a-42c0-9884-c0c143015a47",
          "user_id": 1234,
          "template_id": "d51480ba-ca3f-465c-bc3e-ceb71d73c38d",
          "active": 1,
          "name": "example version",
          "html_content": "<%body%>Click to Reset",
          "plain_content": "Click to Reset<%body%>",
          "subject": "<%subject%>",
          "updated_at": "2014-05-22 20:05:21"

Of interest are the following key pairs for transferring templates intact; :name, :subject, :html_content, :plain_content, and :active. Refer to Template Versions POST action for more information.

Step 3. Backup templates to an external file

The templates (and their versions) will be stored in a JSON file, with the named format as:


This is an additional step meant to safeguard against a complete loss of templates should something happen after transferring templates, e.g., deleting the first account.

Step 4. Create an empty template in Account2

Before any templates can be copied to the second account (transfer to account), a new template needs to be created. A name is required to create the new template; the :name key pair saved in Step #1 is used in this step. A prepend string can be configured to distinguish the new template from any existing templates in the second account:

curl -H "Content-Type: application/json" -X POST -d {"name":"Prepend_text"+"template_name"}


1. Newly created template will have a different :id than that of the existing template.

2. If the template already exists, template creation will fail, and a 400 response is returned. There is currently no check to skip already created templates, and it is unknown how the process will fail as this scenario has not been tested yet.

3. Version names must be unique across templates within an account.

Step 5. Populate template

Transfer the template content to the newly created template, using the Template Versions API.

curl -H "Content-Type: application/json" -X POST -d @template_content.json

The versions of each template is pushed, one at a time, to the new template, using the required key pairs described in Step #2. As a safeguard, all other information is stripped from the version before pushing changes, i.e., information such as :user_id and :updated_at, as these are regenerated on transfer.

Step 6. Wash, Rinse, Repeat

Repeat Steps #2 – #5 for every template in the array retrieved in Step #1. At the end, you should have all templates transferred from your first account to the second!

Back to top