Wednesday, May 13, 2015

Setup iTerm2, zsh, oh-my-zsh and powerline fonts on OSX

After waiting for a long time, I finally updated my Mac to OSX 10.10. Right after the installation, the usual tweaking process begins to make you feel at home. These are my notes to make the shell look good.
I wanted z-shell, oh-my-zsh and these modified powerline fonts to make the command prompt look cool.
If you want to follow these steps, it's recommended to have homebrew installed to install zsh-shell.

Ready, set, go!

Open your terminal and prepare to type.


The easiest way it to install iTerm2 with homebrew. Run this command:
brew install iTerm2


Run this command curl -L | sh


Powerline is a project that provides tools to customize the status line and command prompt of several applications. To achieve this, they use special glyphs that are available through patched fonts. These are the powerline fonts. Download the font from here and install it by double clicking. This will open the Font Book application and install the font for you.


Now it's time to put everything together.
  1. Open iTerm2
  2. Go to Preferences -> Profiles -> Default -> General and type /bin/zsh into the text field next to Command (this will use zsh instead of your default shell)
  3. Go to Preferences -> Profiles -> Default -> Text and change the Regular Font and the Non-ASCII Font to 11pt Inconsolata-dz for Powerline
  4. open ~/.zshrc with your favorite text editor and change ZSH_THEME to agnoster
That's it. Make sure to start/restart iTerm to see all the changes.


oh-my-zsh Powerline change osx shell

Wednesday, May 6, 2015

Electron mystery on OSX solved

Do I look like an idiot? I don't know. But I felt like one for the last 2 days.

2 days ago I started to look into on a great project idea, to replace the Brackets Shell with Electron. Great idea! I wanted to contribute and fix issues that crossed my way. But, I followed the given instruction to clone the repo and setup all dependencies. After everything was download and in the right place, I ran npm start to bring up Brackets in it's new electron shell. But that first attempt failed with this error:
> Brackets@1.3.0-0 start ~/develop/fun/OSS/brackets-electron
> electron .

r CONFIG_PATH = path.resolve(utils.convertWindowsPathToUnixPath(app.getPath("u
TypeError: app.getPath is not a function
    at Object.<anonymous> (~/develop/fun/OSS/brackets-electron/app/shell-config.js:13:71)
    at Module._compile (module.js:418:26)
    at Object.Module._extensions..js (module.js:436:10)

I was wondering, if there was something important missing in the setup instruction, I simply made a mistake or my system config was tricking me. After checking with the guys who started that effort, I was left with this weird error.

I started to research and looked for others having the same issue, but I couldn't find anything. Okay, it has to be my machine setup. Back at home, I started to setup everything on another machine to see if it works there. The result was the same! The error showed up on a different Macs, with a different OSX versions.

I went back to our slack channel and carefully mentioned, that I'm still not able to get it running yet. Someone replied, that I can install Electron globally and try it again. But this turned out to be a red herring. Nothing has changed and it was really frustrating, since nobody else seemed to have these issues on OSX. I promised them to help, but I could even review and test pull requests.

I did some more research and came across this great blogpost from Thorstenhans. He provided a boilerplate project for an app that uses Electron. I was so happy. I followed his instructions to create a clean app. Everything went fine and I was excited because it's using es6. Unfortunately, the result with Electron was the same.

I left a comment for the blogpost asking, if he has encountered this issue before. Nothing worked for me as expected. So, it must be my machine I concluded. But two machines at the same time?

I mentioned my inability to launch Electron on OSX, briefly in the slack channel for electron-brackets. I felt like an idiot at this point. Somebody who distracts everybody with some nonsense. Nobody had an idea what might help to resolve this misery to help me getting started.

Since the electron-brackets version on Linux seemed to work fine, I decided to pull my Linux VM out of the drawer and give it a try. I cloned the repo, installed everything and typed npm start at the console. Guess what? It worked! I was happy. That is awesome and I'm finally able to help.

But I wasn't happy that my day-to-day machine didn't play well with me. I had a conversation with Thorsten Hans (look at the comments here). He solved another mystery for himself along the way, but I didn't make any progress.

Long story short, I started to get rid of my nodejs installation, install nvm from scratch and hoped to resolve the issue. No luck. But then I inspected the environment variables for anything nodejs related and I found NODE_PATH. It seemed somehow messed up. This post recommended to undef NODE_PATH to solve another issue. But it helped me too. npm start is finally working and the biggest mystery, that let me look like an idiot was resolved.


To Thorstenhans for the back and forth to help me resolve the issue. Thanks to Andrew MacKenzie to mention often enough, that the Linux version is doing a good job for him.

Friday, January 2, 2015

Something I Learnt About sed

Note: I’m writing this down to remind myself for the next time I’m using sed and any kind of regex.

I was working on some very simple task: replace a string in a file with a different string.
All of this should happen on our build machine during the product build. Nothing too fancy. But then I got bitten by different versions of sed available on the build machines.
We build our product on OSX, Windows and Linux and I had to realize, that the regex I used, didn’t work with every sed version on the build machines.

My Regex Confusion

To make it clear: I’m not a regex guru. I use it for simple things. When it get’s complex, I usually consult some tools like to get it right.
I started with this simple regex to replace the number after the - (the number of commits). The buildnumber looks like 1.0.0-12345.
Here is the command I started with
`cat build.prop | sed "s/(brackets_build_version=\d+.\d+.\d+-)(\d+)/\1${NEW_COMMITS}/" >`.
The result:
`sed: 1: "s/(brackets_build_versi ...": \1 not defined in the RE`
Okay, that doesn’t help that much. After some research I have found the solution: -E needs to be added to the command.
Okay, that error went away, but the replace didn’t work either. Hm, now I had to debug the Regex and find the issue.
After several rounds of experimentation, I started to read the documentation for re_format. That explained a lot: there are modern RE and obsolete RE (they are sometimes referred to as Basic Regular Expression (BRE) and Extended Regular Expression (ERE)), that mainly exist for backward compatibility. They are not as powerful as the modern RE and lack some features.
The last working version looked like:
`cat build.prop | sed -E "s/(brackets_build_version=[[:digit:]]+.[[:digit:]]+.[[:digit:]]+)-([[:digit:]]+)/\1-${COMMITS}/"`
This worked! Heureka.
But wait, why do I have to used [[:digit:]] instead of the much shorter \d+? I don’t know and probably I will never find out. 

Deploy on Build Machines

Happy, that I finally found a solution that worked on OSX. I totally forgot about the other OSses. Once I made the changes and started the build, it failed on Linux and Windows.
WTH? What was I missing? Why doesn’t it even work on Linux? Quickly started my Linux VM and gave it try. The solution was simple: I had to call sed with -r in order to make it work.

Conclusion or What I have Learnt

sed behaves differently on different OS versions. This is probably no exciting news, but I thought I keep this as a reminder for myself.
Using bash or some derivative of it like cygwin or gitbash on Windows does make a difference for some tools. Especially sed comes in two variants: BSD and GNU.
OSX uses BSD and I guess linux and cygwin come with GNU. They might have different command line switched for the same option. So be careful and testing is always required.
Another difference is the Regex engine tha can be used. sed supports basic regular expressions (BRE’s) and extended (ERE or modern) regular expressions
As I mentioned bofore, enabling the extended regular expressions you need to call sed -E on OSX and sed -r on Linux and cygwin.