What is the difference between .bashrc and .bash_profile?

.bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells.

So, what's the difference between a login shell and an interactive non-login shell?

On most *nix systems, when you login to a terminal, .bash_profile is executed. This happens when you log into your machine, or logging in via SSH. Once logged in, new terminal windows that are opened are launched in "interactive non-login" mode and .bashrc is executed.

A noteable exception, OSX launches all new terminal instances as login shells.

Why different files for login vs non-login?

Perhaps you want to see some additional information when you first log into a box, in addition or instead of the default, "Last login" details. Such as current system load, the next four hours worth of calendar events, or custom ASCII art welcoming you to your machine.

What type of things do I define in my .bash* files?

Here are just a few of the components of my .bash* files. * PATH modifications * ALIAS commands * Convience Bash functions * GIT branch name in prompt with coloring * common macs for work * Ex: cd into application log file direction and begin tailing the most recent log.

Additionally, I have heard of people adding scheduled jobs to their profile that checks for package manager updates to their tool chain, and provide an alert letting the user know updates are avaible.

What if I have multiple machines?

What if you have multiple machines and you would like consistant terminal behavior between them. Simple, use the same configuration files for all the machines. Create a new GIT repo and store your shared config files there. Then, for each machine you use, simply update that machine's .bash* file to source in your shared config files.

Your config file could also automatically pull updates from your repo to ensure each machine is always up to date with your most recent config file.

Interesting Bits from my bashrc file

The following snippet gives me a customized bash prompt. Displays the username and hostname, followed by the current directory in purple, and the git branch I have checked out (when in a git repository) in red.

parse_git_branch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

export PS1='\u@\h \e[35m\w \e[31m$(parse_git_branch)\e[0m$ '

Screen: A Linux Application Every Developer Should Know About

In a previous life, at least it feels like a previous life, I found myself performing a fair amount of remote load testing. I would SSH into a box. Start the application under test, and then need to start any number of monitoring/ metric gathering scripts. Periodically, was the test was progressing, I would return to check on the status of those scripts to determine if there was an issue with the environments real-time.

The trouble I faced, if I left the command running in my terminal, and the SSH session was lost; then the script would be killed. If I launched the process in the background, then I ran the problem of identifying the name of the auto-generated log file that I needed to tail to check on the status. Enter screen.

Screen is a Linux based command line tool to stand up a virtual terminal with all kinds of wonderful features. As the man page describes….

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

At its heart, it allows the developer to SSH into a machine and start a long lived terminal session. Should the SSH session fail, you simply reestablish the connection to the server and then reattach to the running screen session. Furthermore, a single terminal session could spawn several screen sessions, allowing for the concurrent running of several scripts that you want to periodically monitor.

Here is a break down of my most often used commands.

Once inside a screen session, there are a number of useful commands. However, in order to activate the command mode, you must type CNTL-A. Otherwise the command will be interpreted by the terminal within the screen session.