Tyler Cipriani: pages tagged shell

Bash Completion

2017-07-01T00:49:09Z

Links ¶

Basics ¶

Most Debian installed bash completions live under /usr/share/bash_completion/completions

# the first argument ($1) is the name of the command whose  arguments are being completed
# the second argument ($2) is the word being completed,
# and the third argument ($3) is the word preceding the word  being  completed  on the current command line
# In the context of this function the following variables are defined:
# COMP_LINE, COMP_POINT, COMP_KEY, and COMP_TYPE
# as well as COMP_WORDS and COMP_CWORD
#  It must put the possible completions in the COMPREPLY array
# See bash(1) '^  Programmable Completion' for more information
_some_function() {
  local cur cmd
  cur=${COMP_WORDS[$COMP_CWORD]}
  cmd=( "${COMP_WORDS[@]}" )
}
complete -F _some_function command

`complete` options ¶

Some complete options you want:

-o bashdefault - if no completions are found do the bash default thing
-o default - readline completions if both the complete function and bash expansions fail
-o nospace - don’t append a space at the end of matches (useful if you’re doing directory stuffs)
-S or -P - a prefix or suffix that is added at the end of a completion generated by the function passed to complete -F

Example ¶

# Many of the ideas presented in this script were stolen
# in-part or wholesale from
# <https://github.com/git/git/blob/master/contrib/completion/git-completion.bash>
__scap_subcommands=
__scap_get_subcommands() {
    if [ -n "$__scap_subcommands" ]; then
        return
    fi

    __scap_subcommands=$(scap --_autocomplete)
}

_scap() {
    local cur cmd=() sub rep

    cur=${COMP_WORDS[$COMP_CWORD]}
    cmd=( "${COMP_WORDS[@]}" )

    if (( COMP_CWORD == 1 )); then
        __scap_get_subcommands
        rep=$( compgen -W "$__scap_subcommands" -- "$cur" )
        COMPREPLY=( $rep )
        return
    fi

    # limit the command to autocomplete to the first 3 words
    if (( COMP_CWORD >= 2 )); then
        # don't complete any sub-subcommands, only options
        if [[ -n "$cur" && "${cur:0:1}" != '-' ]]; then
            COMPREPLY=()
            return
        fi
        cmd=( "${COMP_WORDS[@]:0:3}" )
    fi

    # replace the last word in the command with '--_autocomplete'
    cmd[ $(( ${#cmd[@]} - 1 )) ]='--_autocomplete'

    rep=$( compgen -W "$( ${cmd[@]} )" -- "$cur" )

    COMPREPLY=( $rep )
}

# By default append nospace except when completion comes from _scap
complete -S' ' -o bashdefault -o default -o nospace -F _scap scap

Command-Timing-Bash-Prompt

2017-07-01T00:49:09Z

A few years ago I was using ZSH with Sindre Sorhus’s Pure prompt and generally enjoying the experience. The big, dumb, obvious caveat of using ZSH is that it’s not Bash. As a result, when you SSH into production machines that only have bash installed, you feel a little off-balance. Off-balance is not a feeling you want during an emergency on a live application server. As a result, I switched back to using bash everywhere.

How I learned to stop worrying and love bash. ¶

I never really missed fancy syntax highlighting, or the nice globbing features, or most of ZSH really. The one thing I missed immensely was not so much a feature of ZSH as it was a feature of the Pure prompt I had been using: execution time for long-running commands shown in the prompt.

The time(1) command is a command that I never think to run until it’s too late. The Pure prompt is fancy. By default, if a particular command takes longer than 5 seconds to run, Pure calculates the running time of that command, and renders a human-readable version just above your current prompt.

~
❯ sleep 5

~ 5s
❯ sleep 10

~ 10s
❯

Bash it until it works ¶

Command execution time in Pure uses the preexec and precmd feature of ZSH, which doesn’t exist in Bash. Instead Bash has the less intuitive trap command and the PROMPT_COMMAND shell variable.

PROMPT_COMMAND is a variable that can be set in your bash config file that, “is executed as a command prior to issuing each primary prompt.” [bash(1)]

trap [-lp] [arg] [sigspec] can be used to listen for the DEBUG signal. “If a sigspec is DEBUG, the command arg is executed before every simple command”

Using these two tools in conjunction, you can approximate preexec and precmd:

debug() {
    # do nothing if completing
    [ -n "$COMP_LINE" ] && return

    # don't cause a preexec for $PROMPT_COMMAND
    [ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return

    echo 'debug'
}

prompt() {
    echo 'prompt'
}

trap 'debug' DEBUG
PROMPT_COMMAND=prompt

So now debug is executed before each “simple command” and prompt is executed before each issuing the primary prompt.

$ echo 'hi'
debug
hi
prompt

Timing each command is then pretty trivial:

debug() {
    # do nothing if completing
    [ -n "$COMP_LINE" ] && return

    # don't cause a preexec for $PROMPT_COMMAND
    [ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return

    start_time=$(date +'%s')
}

prompt() {
    end_time=$(date +'%s')

    echo "$(( end_time - start_time )) seconds"
}

trap 'debug' DEBUG
PROMPT_COMMAND=prompt

$ sleep 2
2 seconds
$

Integrating that into the prompt and making it look pretty is just a little-bit of code away:

# Human readable time output
# e.g., 5d 6h 3m 2s
format_time() {
  local _time=$1

  # Don't show anything if time is less than 5 seconds
  (( $_time < 5 )) && return

  local _out
  local days=$(( $_time / 60 / 60 / 24 ))
  local hours=$(( $_time / 60 / 60 % 24 ))
  local minutes=$(( $_time / 60 % 60 ))
  local seconds=$(( $_time % 60 ))
  (( $days > 0 )) && _out="${days}d"
  (( $hours > 0 )) && _out="$_out ${hours}h"
  (( $minutes > 0 )) && _out="$_out ${minutes}m"
  _out="$_out ${seconds}s"
  printf "$_out"
}

debug() {
    # do nothing if completing
    [ -n "$COMP_LINE" ] && return

    # don't cause a preexec for $PROMPT_COMMAND
    [ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return

    start_time=$(date +'%s')
}

prompt() {
    end_time=$(date +'%s')
    time_f=$(format_time $(( end_time - start_time )))

    PS1="${time_f} (•◡•)❥"
}

trap 'debug' DEBUG
PROMPT_COMMAND=prompt

 (•◡•)❥ sleep 5
5s (•◡•)❥

Motherfucking magic.

Development Environments with Vagrant, Docker, and Supervisord

2017-07-01T00:49:09Z

I’ve used Vagrant a fair amount in my day, and it’s great. I enjoy being able to spin-up toy linux environments to test out ideas. I tend to use the Chef provisioner with Vagrant to build-out a local environment that matches my server fairly closely.

My Ever-Evolving Rant About DevOps ¶

I’ve been thinking about Chef a lot lately. Often is the time, in moments of profound frustration, that I’ve had the thought that Chef is nothing more than a useless, leaky abstraction that separates me from something I know fairly well—Linux.

This thought is usually fleeting: Chef provides many needed abstractions that are, ultimately, much easier to grok than the underlying Linux system. Further, Chef allows you to keep a(n ostensibly) well-tested system under version control.

I’ve come to the realization that my problem with Chef is not really a problem with Chef, but a problem with Linux itself.

Linux system administration is difficult because Linux commands are non-deterministic and rely heavily on system state (e.g., installed software, permissions, network settings and availability). Maintaining a bare-metal, long-running server non-interactively using Chef sucks because any hand-tinkering via ssh is going to fuck with the “state” of the system—creating different results for subsequent chef-client runs. This system state adjustment may or may not be reflected in the chef repository (which double sucks).

Why Docker Curtails My Rage ¶

I started to think about Docker. I feel Docker addresses the problem of program state better than other currently available solutions (although, Nix is looking pretty promising as well). While Docker is still a Linux system—and, ipso facto, state-dependant—it’s also ephemeral and therefore, by not persisting changes to state, Docker has created a previously unavailable (on bare metal hardware), lightweight workaround to the problem of system state.

As is my wont, I decided today to play a bit with Docker on Vagrant and, lo-and-below, I found that the newest version of Vagrant (1.6.2, as of May 26th) can actually use docker as a provider, that is, as an alternative to VirtualBox. Using Docker as a provider means that you can run a fully-independent development enviroment, on your host machine without the overhead of VirtualBox. Neat.

“Imma setup a local development environment for Ubuntu 14.04, nginx and php-fpm using Vagrant, Supervisord and Docker,” says I.

Project Layout ¶

To keep my project directory nice and tidy, I’ve separated-out most of the files needed by the Docker provider into a Docker folder. This results in the directory structure below.

├── Docker
│   ├── Dockerfile
│   ├── nginx
│   │   └── default
│   ├── php-fpm
│   │   └── php-fpm.conf
│   └── supervisor
│       └── supervisord.conf
├── Vagrantfile
└── www
    └── index.php

The Dockerfile is used to build the main docker machine and the subfolders in the Docker directory contain configuration used in the Dockerfile.

The www folder is my fake php project folder.

VagrantFile ¶

Since docker handles so much of what was previously handled by Vagrant provisioner, the Vagrantfile for a Docker-backed Vagrant instance is pretty sparse.

In mine, I’ve got:

Vagrant.configure(2) do |config|
  config.vm.synced_folder "./www", "/var/www"   # Sync'd folder

  config.vm.provider "docker" do |d|
    d.build_dir = "./Docker" # specifies the path to the Dockerfile
    d.ports << '8080:80'     # Forwards port 8080 from the host to the Docker Container port 80
  end
end

Dockerfile ¶

Most of the work of provisioning a container is handled by Docker and the Dockerfile. In fact, if you were only ever going to run this container on a Linux machine, I don’t think that Vagrant adds any needed functionality to the docker.io cli. In terms of portability, however, Vagrant is, at this time, a necessary evil to run docker on OSX and Windows.

FROM ubuntu:latest

MAINTAINER Tyler Cipriani, tyler@tylercipriani.com

# Download and install php, nginx, and supervisor, hey, just linux for a change!
RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get -y dist-upgrade
RUN apt-get install -y php5-fpm nginx supervisor

# Setup config files
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
ADD ./nginx/default /etc/nginx/sites-enabled/default
ADD ./supervisor/supervisord.conf /etc/supervisor/supervisord.conf
ADD ./php-fpm/php-fpm.conf /etc/php5/fpm/php-fpm.conf

# Shared volume
RUN mkdir -p /var/www
VOLUME ["/var/www"]

# Default command for container, start supervisor
CMD ["supervisord", "--nodaemon"]
USER root

# Expose port 80 of the container
EXPOSE 80

This Dockerfile takes care of building a docker container from the latest Ubuntu image (14.04 as of May 26th, 2014). Running this code installs:

Nginx 1.6.0
PHP 5.5.9
Supervisor

This config also starts supervisor with the --nodaemon flag by default. Docker can run a container running a non-daemonized program as a daemon (much like supervisor can run non-daemonized programs as daemons). Supervisor is used as a way of running both nginx and php-fpm as non-daemonized programs. It is also noteworthy that the dockerfile creates and/or modifies configuration files for php-fpm and nginx to make sure they both run in non-daemon mode.

nginx/default

server {
  listen 80 default_server;

  root  /var/www;
  index index.php index.html;

  # pass the PHP scripts to FastCGI server
  location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
  }
}

php-fpm/php-fpm.conf

[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
daemonize = no

include=/etc/php5/fpm/pool.d/*.conf

supervisor/supervisord.conf

[unix_http_server]
file=/var/run/supervisor.sock   ; (the path to the socket file)
chmod=0700                       ; sockef file mode (default 0700)

[supervisord]
logfile=/tmp/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB        ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10           ; (num of main logfile rotation backups;default 10)
loglevel=info                ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false               ; (start in foreground if true;default false)
minfds=1024                  ; (min. avail startup file descriptors;default 1024)
minprocs=200                 ; (min. avail process descriptors;default 200)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL  for a unix socket

[program:php5-fpm]
command=/usr/sbin/php5-fpm -c /etc/php5/fpm
stdout_events_enabled=true
stderr_events_enabled=true

[program:nginx]
command=/usr/sbin/nginx
stdout_events_enabled=true
stderr_events_enabled=true

Jam Time ¶

With all of our configuration in place there isn’t much left to do aside from running the vagrant instance and allowing docker to create our container.

$ sudo docker pull ubuntu # to grab the latest Ubuntu image, Vagrant should probably do this but doesn't
$ sudo vagrant up --provider=docker --debug # use debug if you don't want to sit waiting with no info for a long time on the first run

With that, you now have a container running nginx and php-fpm that is sharing a folder with you at /var/www. Navigating to http://localhost:8080/index.php should show you the contents of your ./www/index.php file.

This process is really simple AND super lightweight. I’ve been running my docker/vagrant instance for about 45 minutes alongside chrome and tmux/xterm without any noticeable jankyness on a notoriously janky laptop.

Create a Baller/Useful MOTD with ANSI Art

2017-07-01T00:49:09Z

EDIT: 2017-01-08

Igor Rzegocki has a project that uses the same technique outlined here to make some incredible ready-made Street FIghter MotDs – it is really cool, and if you are interested in abusing ansi escape sequences to make MotDs you should check it out :)

Zangief MOtD

Everyone universally agrees that most Message of the Days (MOTDs) are stupid and suck. By the end of reading this post, your mind grapes should be swollen with the knowledge of how to make an MOTD that isn’t stupid and, some would say, doesn’t suck.

Prerequisites ¶

Imagemagick
OpenJDK
coreutils
perl
git

This should have you covered:

$ sudo apt-get install imagemagick openjdk-6-jdk coreutils perl git

Creating the Util-say file ¶

I use Util-Say to create motd messages. I started out using img2xterm, but I’ve found I get better results with Util-Say.

$ git clone https://github.com/maandree/util-say
$ cd util-say
$ ./img2ponysay -- yourimg.png > yourimg.txt

You can also try ./img2ponysay -2 -- youimg.png > yourimg.txt but I’ve never had good results with that

MOTD-ifying ¶

Mammoth Motd

On CentOS and Debian, I usually just throw the ponysay file directly into /etc/motd and maybe add on some other useful info:

$ sudo cat yourimg.txt > /etc/motd
$ sudo figlet "$(hostname)" >> /etc/motd
$ sudo printf "Public IP: $(dig +short myip.opendns.com @resolver1.opendns.com)\n" >> /etc/motd

On Ubuntu Boxes (since they use update-motd(1)), I do pretty much the same thing except I just make a bash script in /etc/update-motd.d/25-baller-motd

#!/usr/bin/env bash
cat yourimg.txt
figlet "$(hostname)"
printf "Public IP: $(dig +short myip.opendns.com @resolver1.opendns.com)\n"
command -v fortune &> /dev/null && fortune

There are likely better articles on creating a useful MOTD, (here’s one that looks kinda cool) but there are exactly none-better articles on creating MOTDs that are so flossy!

Replacing Jekyll with Pandoc and a Makefile

2017-07-01T00:49:09Z

EDIT: 2016-08-19

I got an email a very long time ago that I meant to post about on ye old weblog from a fellow named Tom Duck who built a CMS based around some of the ideas presented here.

It’s called Bassclef and it looks pretty amazing and folks should check it out.

I used to use del.icio.us to keep track of links, then it went away. After del.icio.us shutdown, I used a ton of uniquely awful services to keep track of links. Eventually, I came around to the idea that all I needed was a series of markdown files and github: BOOM! Public link repositiory—just like del.icio.us back in the day.

After a while I started thinking, I could make these files a lot more presentable if I did some jekyll-ifying and served them out on github.

Previously Jekyllfied ¶

My linuxtips repo is just a dumb jekyll repo. Esentially all linuxtips is is just a big README file. So, for that repo, I created a gh-pages branch with a _config.yml and a _layout directory and popped in a Makefile:

INDEX = ${CURDIR}/index.md

$(INDEX):
  @ git show origin/master:README.md > $@
  @ perl -i -pe 'print "---\nlayout: default\ntitle: Linux Tips\n---\n\n" if $$. == 1;' $@

and then I got tylercipriani.com/linuxtips; neat.

I ran into some problems with that approach along the way. Mostly problems with git and the separate branches and the order in which I’d commit and pull and whatever, it was/is a headache.

Pandoc ¶

I started thinking about Pandoc. Pandoc is this haskell library that makes miracles of text happen.

Got an org-mode file and need TeX? Done.

Got a markdown slideshow that needs to become a beamer slide show? OK, sure.

Fuck Beamer, how about markdown slides → Reveal.js slides? You bet your sweet sensual bologna.

Imma install Pandoc… ¶

Debian? ¶

sudo apt-get install haskell-platform
cabal update
cabal install pandoc

then add it to your path in your .${SHELL}rc file:

[ -d "$HOME/.cabal/bin" ] && export PATH="$HOME/.cabal/bin:$PATH"

OSX? ¶

brew update
brew install pandoc

Imma Use Pandoc… ¶

Alright, so I’ve got tons of markdown files, fairly structured, with bunches of links and I need html5. I’ll create a Makefile proof-of-concept for this:

index.html: README.md
  pandoc -s -f markdown -t html5 -o "$@" "$<"

Running make takes my README.md and makes this:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="generator" content="pandoc">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
  <title></title>
  <style type="text/css">code{white-space: pre;}</style>
  <!--[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
  <![endif]-->
</head>
<body>
<h1 id="tyler-ciprianis-bookmarks">Tyler Cipriani's Bookmarks</h1>
<p>In an effort to <em>not</em> have 100+ tabs open…</p>
<ul>
<li><a href="http://www.flickr.com/photos/tylercipriani/">My Photography</a></li>
<li><a href="Design.md">Design</a></li>
<li><a href="Development.md">Development</a></li>
<li><a href="Business.md">Business</a></li>
<li><a href="Fun.md">Fun</a></li>
</ul>
</body>
</html>

Title/Layout/CSS ¶

So now that I’m outputting html, I still need to be able to:

Configure a layout in which to render html
Include a css file in said layout
Add post metadata to my layout (e.g., title, headline, etc.)

Pandoc is able to do all of these things—easy-peasy-lemon-squeezy.

First, to establish a layout, let’s copy the default html5 layout file for Pandoc:

pandoc -D html5 > _layout.html5

I’ll make some small tweaks to that file, keep the variables I need, ditch the variables I don’t need. Here is the html5 layout file I came up with:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <title>$if(title-prefix)$$title-prefix$ - $endif$$pagetitle$</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Open+Sans:800">
$for(css)$
  <link rel="stylesheet" href="$css$">
$endfor$
</head>
<body>
  <!--[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
  <![endif]-->

  <main class="container">
    $body$
  </main>

</body>
</html>

Next, I need to figure out how to include a css stylesheet. A quick search for css in pandoc(1) turns up the --css flag which enables you to link to a css stylesheet.

Updated Makefile:

index.html: README.md
  pandoc -s --template "_layout" --css "css/main.css" -f markdown -t html5 -o "$@" "$<"

Finally, I need to be able to include a unique <title> tag string for each page. Again, a search through pandoc(1) for variable yields results; using the -V flag enables you to set template variables using -V [KEY]=[val].

A bit more digging in the online docs, however, nets better solution: YAML Metadata blocks—just like jekyll!

So, for each markdown file in my repo, I’ll add a block to the top that looks like this:

---
pagetitle: <pagetitle>
---

$pagetitle$ is the variable I defined in my _layout.html5 that I’m now passing as a template to Pandoc.

Makefile fanciness ¶

Alright, so now that I have the basics of Pandoc down, I need to whip my Makefile into shape.

First thing is I want to convert ALL of my markdown files to html, not just the README.md. So howzabout I add a wildcard target for all the html files? Also, the whole point of this is to make a github pages site, so let’s add that to the Makefile too

REPO := $(shell git config --get remote.origin.url)
GHPAGES = gh-pages

all: $(GHPAGES) $(addprefix $(GHPAGES)/, $(addsuffix .html, $(basename $(wildcard *.md))))

$(GHPAGES):
  git clone "$(REPO)" "$(GHPAGES)"
  (cd $(GHPAGES) && git checkout $(GHPAGES)) || (cd $(GHPAGES) && git checkout --orphan $(GHPAGES) && git rm -rf .)

$(GHPAGES)/%.html: %.md
  pandoc -s --template "_layout" -c "css/main.css" -f markdown -t html5 -o "$@" "$<"

Running make at this point should checkout your current git repository to a subdirectory called gh-pages (which should be added to .gitignore on master).

This Makefile first tries to checkout an existing gh-pages branch, otherwise it creates a new orphan branch for gh-pages. After that, we glob the current directory for any file name *.md and run it through pandoc, placing the result in gh-pages/[whatever].html

Niceities ¶

I’m a big fan of pre-processors, so the css/main.css file (which doesn’t actually exist as of yet) should be converted from less. The easiest way to do that: add a package.json with less as a dependency.

{
  "name": "linkblog",
  "version": "0.0.1",
  "dependencies": {
    "less": "*"
  }
}

Now running npm install should create a new node_modules directory (which should be added to .gitignore on master). Now we need to add a lessc step to our Makefile.

LESSC    = node_modules/less/bin/lessc
LESSFILE = less/main.less

CSSDIR  = $(GHPAGES)/css
CSSFILE = $(CSSDIR)/main.css

$(CSSFILE): $(CSSDIR) $(LESSFILE)
    $(LESSC) "$(LESSFILE)" "$(CSSFILE)"

$(CSSDIR):
    mkdir -p "$(CSSDIR)"

Also, it’s always nice to have a clean target in any Makefile

clean:
    rm -rf "$(GHPAGES)"

I’d also like to be able to preview before commiting this file by typing make serve

serve:
    cd $(GHPAGES) && python -m SimpleHTTPServer

Finally, speaking of commiting this file, let’s make commit a target, too.

commit:
    cd $(GHPAGES) && \
        git add . && \
        git commit --edit --message="Publish @$$(date)"
    cd $(GHPAGES) && \
        git push origin $(GHPAGES)

Now when I update my links repo’s markdown files I issue a simple series of commands: make checks-out my gh-pages branch and builds the html and css files, make serve lets me look at the output html at localhost:8000, and, finally, make commit pushes those changes live.

So here’s the result and the final Makefile

REPO := $(shell git config --get remote.origin.url)
GHPAGES = gh-pages

LESSC    = node_modules/less/bin/lessc
LESSFILE = less/main.less

CSSDIR  = $(GHPAGES)/css
CSSFILE = $(CSSDIR)/main.css

all: init clean $(GHPAGES) $(CSSFILE) $(addprefix $(GHPAGES)/, $(addsuffix .html, $(basename $(wildcard *.md))))

$(GHPAGES)/%.html: %.md
    pandoc -s --template "_layout" -c "css/main.css" -f markdown -t html5 -o "$@" "$<"

$(CSSFILE): $(CSSDIR) $(LESSFILE)
    $(LESSC) "$(LESSFILE)" "$(CSSFILE)"

$(CSSDIR):
    mkdir -p "$(CSSDIR)"

$(GHPAGES):
    @echo $(REPO)
    git clone "$(REPO)" "$(GHPAGES)"
    @echo "Donezo"
    (cd $(GHPAGES) && git checkout $(GHPAGES)) || (cd $(GHPAGES) && git checkout --orphan $(GHPAGES) && git rm -rf .)

init:
    @command -v pandoc > /dev/null 2>&1 || (echo 'pandoc not found http://johnmacfarlane.net/pandoc/installing.html' && exit 1)
    @[ -x $(LESSC) ] || npm install

serve:
    cd $(GHPAGES) && python -m SimpleHTTPServer

clean:
    rm -rf $(GHPAGES)

commit:
    cd $(GHPAGES) && \
        git add . && \
        git commit --edit --message="Publish @$$(date)"
    cd $(GHPAGES) && \
        git push origin $(GHPAGES)

.PHONY: init clean commit serve

Knowledge Nuggets From My Tmux.conf

2017-07-01T00:49:09Z

When I switched from GNU Screen to Tmux, I was just jazzed that Tmux had a status bar. To achieve that same effect in Screen I had a cryptic 115-character hardstatus string that I copy–pasted from someplace lost to the annals of the Internet Archive.

It wasn’t too long after I made the switch until I felt that old hacker itch and began scouring Github for Tmux tips.

You can view my complete tmux.conf on my github

Tmux Tips for the Uninitiated ¶

Ctrl-f Meta is for super stars

I used to always bind Ctrl-a to Meta to make Tmux behave like Screen; however, when you use Screen inside Tmux (as I often do with our AWS servers), hitting Ctrl-a a can get pretty tiresome. Plus, you can’t use Readline very effectively without Ctrl-a
```
unbind-key C-b #no more Ctrl-b
# Switch me to ^f, thanks
set-option -g prefix C-f
bind-key f send-prefix
```
Faster escape

When I first started using Tmux I couldn’t stand the amount of time it took to enter copy-mode. Then I realized—I didn’t have to.
```
set-option -sg escape-time 0
```
Maximize Panes

One of the things I love about Vim splits is that you can hit Ctrl-w | to maximize the current pane and hit Ctrl-w = to bring it back to an even split. Bringing that functionality to Tmux is very powerful and super easy. This line will let you hit Meta | to maximize a single pane and then hit Meta | again to bring it back to the original split.

Warning: this is a tip that will only work with tmux 1.8+ (check your version via tmux -V)
```
bind-key | resize-pane -Z \; display-message "Zoom zoom zoom"
```
Vim-esque system clipboard copy–paste

Sometimes system clipboard support from Vim isn’t enough. It’s convenient to be able to pull whatever is in your Tmux buffer onto your system clipboard (preferably without having to memorize any new keybindings and without overwriting any existing keybindings).

First, I set the window mode-keys to use Vi bindings:
```
set-window-option -g mode-keys vi
```
Next, I bind Meta Esc to enter Tmux copy-mode:
```
unbind-key [
bind-key Escape copy-mode
```
After that, I bind visual-selection and copy keys inside vi-copy mode to their Vim equivalents:
```
bind-key -t vi-copy 'v' begin-selection
bind-key -t vi-copy 'y' copy-selection
```
Finally, I bind Meta y to execute a shell command. This should work on either Linux or OSX, although I’ve only tested this on OSX:
```
if-shell 'test "$(uname -s)" = "Darwin"' 'bind-key y run-shell "tmux show-buffer | pbcopy" \; display-message "Copied tmux buffer to system clipboard"'
if-shell 'test "$(uname -s)" = "Linux"' 'bind-key y run-shell "tmux show-buffer | xclip -sel clip -i" \; display-message "Copied tmux buffer to system clipboard"'
```
OSX Specific Tmux file

Even though Tmux and Vim are really popular on OSX—they are, essentially, broken. You have to do the whole reattach-to-user-namespace thing to get Vim’s clipboard to play nicely inside Tmux. This mess makes your tmux.conf look more cluttered and makes your dotfiles a little less portable. To fix this I keep an OSX Specific tmux.conf.
```
#dumb osx
if-shell 'test "$(uname)" = "Darwin"' 'source ~/.tmux-osx.conf'
```

Steve Losh’s Bad Wolf Status Bar

News Flash: Steve Losh makes cool looking stuff. In Steve’s version of this he uses a small script to get his unread email count from his local offlineimap folder. In the version below I use a little bash script I wrote to grab weather info (that I call weathermajig).

# Bad Wolf by Steve Losh
# =====================
set -g status-fg white
set -g status-bg colour234
# set -g status-bg default #set for transparent background
set -g window-status-activity-attr bold
set -g pane-border-fg colour245
set -g pane-active-border-fg colour39
set -g message-fg colour16
set -g message-bg colour221
set -g message-attr bold
# Custom status bar
# Powerline
set -g status-left-length 32
set -g status-right-length 150
set -g status-interval 5
# Lets add the current weather to our status bar—why? Well Why the french-toast not?
set -g status-left '#[fg=colour16,bg=colour254,bold] #S #[fg=colour254,bg=colour238,nobold]#[fg=colour15,bg=colour238,bold] #(weathermajig boulder --short) #[fg=colour238,bg=colour234,nobold]'
set -g status-right '#[fg=colour245]❬ %R ❬ %d %b #[fg=colour254,bg=colour234,nobold]#(rdio-current-track-tmux)#[fg=colour16,bg=colour254,bold] #h '
set -g window-status-format "#[fg=white,bg=colour234] #I #W "
set -g window-status-current-format "#[fg=colour234,bg=colour39]#[fg=colour16,bg=colour39,noreverse,bold] #I ❭ #W #[fg=colour39,bg=colour234,nobold]"

Dotfile Boilerplate

2017-07-01T00:49:09Z

Earlier today I made a tweak to one of my ever-growing collection of dotfiles and it reminded me that I’m not too happy with my dotfile’s bootstrap script.

The bootstrap file that I have in my repo is from a 2008 blog post and I’ve never been too thrilled with it.

The problems my old boostrap were

It required that Ruby be installed—which was a pain on production servers where I never intended to have Ruby installed.
It overwrote any existing dotfiles in $HOME without warning
It added every sub-directory/file in the .dotfiles directory—you couldn’t add a README.md file without it being symlinked in the $HOME directory as .README.md—silly, right?!

Long story short—I needed a new bootstrap file. I’m a big believer in not reinventing the wheel, so I went looking for the canonical example of the dotfile bootstrap file.

I started perusing dotfile repos on github—which is always exciting to me (because I’m super nerdy) and there are some amazing dotfile resources on github:

Seeing all of this got me to thinking—wouldn’t it be great if there were a project that amalgamated all of this fun stuff? Like HTML5 Boilerplate for dotfiles.

The project will keep canonical examples of files like the bootstrap script. It would also keep an opinionated list of functions, aliases and configurations that could help beginners get a great start and normalize dotfile distribution in the same way that pathogen normalized vim plugins into bundles.

Dotfile Boilerplate ¶

So there’s the starting point: Dotfile Boilerplate

At the very least it’s a solidly structured start with an amazing bootstrap script that I modfied based off of Zach Holman’s setup.

So that’s the whole idea—the hope is that this repository can grow and collect great ideas, functions, and well-considered dotfiles from interesting discussions and people around the internet.

Beginners will have an amazing starting point and advanced users will have a wellspring of ideas.

Fork ‘em if ya got ‘em.

Vim, the OSX clipboard and Tmux

2017-07-01T00:49:09Z

I’ve been an Ubuntu user for 4 years now. Since I started working at Upsync 3 months ago, I’ve found myself a very lonely desktop Linux user. Also, since this job is my first heavy-duty exposure to back-end web development, I’ve found myself a very confused desktop Linux user.

While there are many tools for working on a website backend available in Ubuntu, few are as shiny as those available in OSX (Charles Proxy, usable in Chrome. I want that. I want it hard.). Also, want to do any iOS work? (you know I do)—then you must have a mac.

On the flip side there is my natural inclination to be a bit of a contrarian and principles and such…

##…but it’s so shiny!

I’ve caved. I’m a sell-out. I’m not the cool hardcore ideologue I once believed myself to be. You know those hypothetical, which-side-of-history-would-you-be-on-type, questions? Well, I can now safely say that I would not have been in the French Resistance.

I’m typing this on the beautiful back-lit keyboard of a brand-new, core-i7-having, 8GB-RAM-possesing, 256GB-SSD-not-spinning monster that is a 13″ MacBook Air.

##I thought this was supposed to be easy

The first thing I did was get iTerm 2 up and running and then install Homebrew. After removing the dumb “Natural” scrolling and using PCKeyboard hack to remap some keys, I’m working exactly as I was before. I really can’t tell a difference. Which is a little anti-climactic for a computer that cost as much as my first car (oh, how I miss that purple Taurus!).

It was really easy to get everything set up as it was before, except…Vim…my clipboard…Tmux…they didn’t work together and that was CRIPPLING! Seriously, I depend on those things working together.

This post is written as a little reminder to myself of how I got it all up and running again.

##The process

Install Homebrew:
Instructions are available on Github but really all it boils down to is: ruby -e “$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)”
Install MacVim:
And make sure it overrides the system default Vim, which is pre-7.3 Vim and sucks (or it was last week when my MacBook got here) use: brew install macvim –override-system-vim
Install Tmux:
Easy peesy lemon squeezy: brew install tmux
Thank the good, sweet lord for Paul Hinze:
Install Paul’s reattach-to-user-namespace hack via homebrew: brew install reattach-to-user-namespace –wrap-pbcopy-and-pbpaste
Append your ~/.tmux.conf file:
With this lovely gem: set-option -g default-command “reattach-to-user-namespace -l zsh” or you can use bash, I guess, I don’t know because I use ZSH. That should be a step somewhere…chsh -s /bin/zsh. Done.

Now if only OSX Mountain Lion possessed the awesome power of moving windows between workspaces using keyboard shortcuts. Someday… someday.

My ZSH (and bash) prompt

2017-07-01T00:49:09Z

Junkfood theme in git directory

In order to become a card-carrying Linux user, I feel like you need to have spent a truly astounding amount of time fiddling with your dotfiles.

Me? I’ve gone way beyond the point of diminishing returns. Past the point where anyone who loves me can even feign interest. And now I’m quaffing the sweet nectar of victory, and that victory nectar is sweet. Oh yes, that’s right: my insanely customized prompt is now a part of Bobby Russell’s Oh-My-ZSH

I’m feeling the pride, joy, and anxiety that can only come from watching my little utf-8 baby move beyond my home directory and march deep into the uncharted home directories of what I can only assume are BILLIONS of users.

All your Oh-My-ZSH are belong to us! * ¶

…or it will when you update your theme. See, cause, oh-my-zsh uses themes to specify how your prompt looks. You can define what theme you’d like to use in your ~/.zshrc file. On or around line 8 you’ll want to update the line that starts with ZSH_THEME=… to look like this:

# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
ZSH_THEME="junkfood"

Almost, not quite… ¶

Like any good dotfile obsessive, I’ve continued to make changes to this prompt since I made my pull request to ole Robby! I’ve modified the prompt to show the same sort of branch information about SVN repos that it currently displays for git repos (e.g., current branch name and local modifications). That little code chestnut is available over on my fork of the oh-my-zsh build.

Bash Junkfood theme ¶

I also have a version of this prompt for Bash that I’ve made in preperation for the undoubted overwhelming demand that I expect to begin any time now:

# An extravagent PS1 http://blog.bigdinosaur.org/easy-ps1-colors/
function prompt {
  # 30m - Black
  # 31m - Red
  # 32m - Green
  # 33m - Yellow
  # 34m - Blue
  # 35m - Purple
  # 36m - Cyan
  # 37m - White
  # 0 - Normal
  # 1 - Bold
  local BLACK="\[\033[0;30m\]"
  local BLACKBOLD="\[\033[1;30m\]"
  local RED="\[\033[0;31m\]"
  local REDBOLD="\[\033[1;31m\]"
  local GREEN="\[\033[0;32m\]"
  local GREENBOLD="\[\033[1;32m\]"
  local YELLOW="\[\033[0;33m\]"
  local YELLOWBOLD="\[\033[1;33m\]"
  local BLUE="\[\033[0;34m\]"
  local BLUEBOLD="\[\033[1;34m\]"
  local PURPLE="\[\033[0;35m\]"
  local PURPLEBOLD="\[\033[1;35m\]"
  local CYAN="\[\033[0;36m\]"
  local CYANBOLD="\[\033[1;36m\]"
  local WHITE="\[\033[0;37m\]"
  local WHITEBOLD="\[\033[1;37m\]"
  export PS1="$WHITEBOLD# $GREEN\u$WHITEBOLD. $BLUE\h$WHITEBOLD. $YELLOW\d$WHITE at $PURPLE\@$WHITEBOLD. $CYAN\w\n  $WHITE"
}
prompt

Prompt Inspiration ¶

Most of the inspiration for moving to ZSH and for creating this extravagant (to borrow a phrase) prompt came from a blog post written by Mr. Steve Losh called, “My Extravagant ZSH Prompt”.

Tyler Cipriani: pages tagged shell

Bash Completion

Links ¶

Basics ¶

complete options ¶

Example ¶

Command-Timing-Bash-Prompt

How I learned to stop worrying and love bash. ¶

Bash it until it works ¶

Development Environments with Vagrant, Docker, and Supervisord

My Ever-Evolving Rant About DevOps ¶

Why Docker Curtails My Rage ¶

Project Layout ¶

VagrantFile ¶

Dockerfile ¶

Jam Time ¶

Create a Baller/Useful MOTD with ANSI Art

Prerequisites ¶

Creating the Util-say file ¶

MOTD-ifying ¶

Replacing Jekyll with Pandoc and a Makefile

Previously Jekyllfied ¶

Pandoc ¶

Imma install Pandoc… ¶

Debian? ¶

OSX? ¶

Imma Use Pandoc… ¶

Title/Layout/CSS ¶

Makefile fanciness ¶

Niceities ¶

Knowledge Nuggets From My Tmux.conf

Tmux Tips for the Uninitiated ¶

Dotfile Boilerplate

Dotfile Boilerplate ¶

Vim, the OSX clipboard and Tmux

My ZSH (and bash) prompt

All your Oh-My-ZSH are belong to us! * ¶

Almost, not quite… ¶

Bash Junkfood theme ¶

Prompt Inspiration ¶

`complete` options ¶