Forem: Nick W

My three steps to more manageable bash profiles

Nick W — Wed, 25 Oct 2017 13:17:52 +0000

Sources

great blog post on load order
an insightful SO question

The Problem

I work on a Linux distro called BioLinux, which is built on top of Ubuntu 14. This came with zsh as the default shell. As I have been transitioning into the computer world from being a lab biologist, I had a lot of questions starting out. One recurring question was how to set the $PATH variable. Every time I tried to install a new program, I was faced with a decision: do I change the path in .bashrc, .bash_profile, .zshrc, or .profile? I ended having spaghetti code calling all of those in some order. Each was a mix of variables, aliases, custom function, and so on.

Things got even more complicated when I would ssh into this computer and discover that the $PATH variable was different or missing.

Later, I started to work more and more on remote machines, and wanted to have my settings the same across the different shells. Some of these machines have both zsh and bash, others just have bash.

This past weekend, I sorted out my mess, and wanted to share what I see as a managble solution (for now!).

Fix #1: Stick to one shell

Half of my confusion was due to working in zsh on my main machine, and in bash on the three remote machines I regularly use. I never had any issues with zsh, but after some googling, I discovered that I was not making use of all of zsh's features. So I decided to switch back to good 'ol bash for two reasons:
1) to keep things the same across all the machines I use.
2) to simplify. I clearly was not using zsh as it could be used, and so I made the decision to move to bash until I felt I needed the extras that zsh offers.

chsh -s /bin/bash myuser

Fix #2: Keep things the same between interactive, and non-interactive shells

https://superuser.com/questions/183870/difference-between-bashrc-and-bash-profile

I still don't understand the in's and out's of this, but .bashrc isn't checked whenever you open a new shell -- .bash_profile is. But as I wanted my settings to be called both in login shells and over ssh sessions, etc, I simplified the structure by changing my .bash_profile to the following 3 lines:

if [ -f ~/.bashrc ]; then
   source ~/.bashrc
fi

So, when I open a new shell, .bash_profile is called, which then loads everything I have in my .bashrc; this way, I get the same behaviour no matter when I login from or what I am doing.

Fix #3: Separate machine-specific things from convenience things

I like having nice colors in my shell, custom aliases, git status in my prompt, and other fun stuff. I wanted to have the same aliases, functions, and color setting on each of my machines. But I couldn't just copy my .bashrc to different machines, as the $PATHs would be different.

My solution was to go through my .bashrc and move all the me-specific things to a new file, which I called .nickstuff. Then, I added the following line to the end of my .bashrc

source ~/.nickstuff

Now, when I get access to a new machine, I can move that .nickstuff file to my new machine's home directory, add that same line to the new machines .bashrc, and I have access to all the features the make my life easier.

For those curious, here is what I have in my .nickstuff file:

##### stuff fo aesthetics, etc
alias pyclean='find . | grep -E "(__pycache__|\.pyc|\.pyo$)" | xargs rm -rf'
alias duh="du ./ --max-depth 1 -h"
alias diffy='diff -y --suppress-common-lines'

if [ "$HOST" = 'gruffalo' ]; then
    export HOST_COLOR="\[033[1;36m\]"
fi


# custom
kptrk(){
    source ~/.bash-preexec.sh
    if [ "$KPTRK_ON" = true ]
    then
    echo "KeePTRacK is disabled"
    preexec() { true; }
    precmd() { true; }
    export KPTRK_ON=false
    export KPTRK_DIR=0
    else
    export KPTRK_DIR=$(pwd)
    echo "KeePTRacK is enabled!"
    preexec() { printf "$(date)\t$1 \n">> $KPTRK_DIR/kptrk_README; }
    precmd() { echo "kptrk is on"; }
    export KPTRK_ON=true
    fi
}

# get rid of files added when running setup.py
rmsetup(){
    python setup.py install --record files.txt
    cat files.txt | xargs rm -rf
}

# prompt stuff
# my default PS1
export PS1_def="\[\033[38;5;49m\]\u\[$(tput sgr0)\]\[\033[38;5;15m\]@\[$(tput sgr0)\]\[\033[38;5;34m\]\h\[$(tput sgr0)\]\[\033[38;5;15m\][\[$(tput sgr0)\]\[\033[38;5;139m\]\W\[$(tput sgr0)\]\[\033[38;5;15m\]]\$(__git_ps1) \[$(tput sgr0)\]"

# teaching PS1
export PS1_teach="\[\033[38;5;202m\]\u\[$(tput sgr0)\]\[\033[38;5;15m\][\[$(tput sgr0)\]\[\033[38;5;10m\]\w\[$(tput sgr0)\]\[\033[38;5;15m\]] \[$(tput sgr0)\]"

export PS1=$PS1_def
EDITOR=/usr/bin/nano

Conclusion

In the end, I am happy with this setup. I have all my $PATH and $LIBs set in my .bashrc, and all my convenience functions, prompts, etc set in my .nickstuff file that is easy to move to a new machine.

I hope you found this useful! For me, it is much easier to manage my settings this way, but I'm sure that most of you have a solution that works well for you; please share in the comments!

Notes on Nativescript: my first steps into mobile development

Nick W — Wed, 19 Apr 2017 08:47:40 +0000

Introduction

Background

I started listening to Programming Throwdown a few years back, when I first started making the transition from a wet-lab scientist to a computational biologist. I exchanged my world of pipettes, centrifuges, and petri dishes for my trusty old thinkpad, slowly learning the lingo and skills needed to succeed. PT helped acquaint me with the many languages and ecosystems in the programming world. Last year, they ran an episode looking at Nativescript, and I was intrigued. As I did not know Swift or Java, I had figured mobile development was not in the cards for me, but their description of Nativescipt piqued my interest. Could I really make mobile apps just using Javascript and XML? I decided to try.

First things

That being said, I knew nothing about JS or XML. I read Eloquent Javascript, and set up a minimal dev environment after reading Kamil's post, and slowly started building up the logic behind the app I hand in mind (essentially, a replacement to a years-old spreadsheet of lab calculations). I started to enjoy programming in JS; there are plenty of times I got caught by weird type conversions, but overall, it was similar enough to languages I already new (Python, R, C) to not be too tricky. The amount of support available online is fantastic.

What follows is simply a few reflections on my experience, and what I would recommend for anyone looking to get started.

NOTE: I am in no way an expert; I simply want to share my experience working with Nativescript as a non-expert, JS-novice, mobile-ignorant layman.

Nativescript Lessons

Lesson #1: Avoid the paradox of choice

Nativescript has some of the best documentation of any framework I have used. It has clearly worked minimal examples, and walks you through a increasingly complex grocery list app to get the hang of things. All was going well, so to jump in, I cloned a demo app that used the drawer navigation system I had in mind.

And that is where I noticed something funny. This demo app was written in Typescript! Not a problem, I though, I will just javascript-ify it and move on. But, that was the first of many such "huh?" moments.

One of the beauties of Nativescript is its flexibility. You can write in TypeScript or JavaScript. You can structure the project may different ways. It is endlessly extensible with plugin and modules. However, that can make finding template examples tricky to work with. Often, if you try to implement a minimal example from an interesting plugin, you may well find that it requires a lot of reworking to get working. So, before starting, look at as many high-quality example repos as you can: find the one that makes the most sense to you, and dive in.

Lesson #2: Multiple ways to skin a cat

Similar to the last lesson, Nativescript itself is very flexible. When I first got started, it seemed straightforward enough: js for the logic, xml for the structure, and css for the style. How hard can it be?

What I learned after a while working on my app was that that understanding is a simplified version of reality. If you want (and you probably will, once you see how it can help), you can set the style in the xml sheet, and set the structure of the page in js. Why would you want to do that? Simply, it allows you to bind application logic to the layout of pages, so that you can dynamically change the UI based on certain things. This is an incredible useful feature, but (I felt) poorly explained in the literature.

This led to lots of "huh?" moments looking at examples. The Nativescript docs do have examples of the different ways of doing things, but the way the tutorials go, it is not immediately apparent. Look at the example below for making a grid-layout from the docs, for instance.

The xml:

<GridLayout columns="80, *, auto" rows="auto, *" >
 <Button col="0" />
 <Button col="1" />
 <Button col="2" />
 // by default column and row are set to 0
 <Button row="1" colSpan="3" />
</GridLayout>

or, the js:

//var layout = require("ui/layouts/grid-layout");
var gridLayout = new GridLayout();

var btn1 = new Button();
var btn2 = new Button();
var btn3 = new Button();
var btn4 = new Button();
gridLayout.addChild(btn1);
gridLayout.addChild(btn2);
gridLayout.addChild(btn3);
gridLayout.addChild(btn4);

GridLayout.setColumn(btn1, 0);
GridLayout.setColumn(btn2, 1);
GridLayout.setColumn(btn3, 2);

GridLayout.setColumnSpan(btn4, 3);


// ItemSpec modes of the column refers to its width.
// Absolute size of the column
var firstColumn = new ItemSpec(80, GridUnitType.pixel);
// Star width means that this column will expand to fill the gap left from other columns
var secondColumn = new ItemSpec(1, GridUnitType.star);
// Auto size means that column will expand or shrink in order to give enough place for all child UI elements.
var thirdColumn = new ItemSpec(1, GridUnitType.auto);

// Star and Auto modes for rows behave like corresponding setting for columns but refer to row height.
var firstRow = new ItemSpec(1, GridUnitType.auto);
var secondRow = new ItemSpec(1, GridUnitType.star);

gridLayout.addColumn(firstColumn);
gridLayout.addColumn(secondColumn);
gridLayout.addColumn(thirdColumn);
gridLayout.addRow(firstRow);
gridLayout.addRow(secondRow);

Its a bit hard to see whats going in in the js example. The xml is pretty clear: define a grid with some rows and columns, and place 4 buttons there.

The js does the exact same thing, but from the js file instead of the xml.

That is cool, but it is hard to see immediately what is going on. I found that when I was trying to reuse code examples, a lot of time ended up being spent figuring out whats going on.

Lesson #3: Choose a binding scheme and stick with it.

I didn't come from a web background, so I wasn't familiar with DOM issues that Nativescript attempts to get around. I found the binding schemes available in Nativescript very confusing. Again, the docs are good, but it took some serious tinkering to understand what was going on with static, one-way, two-way, parents, children, inheritance, etc. What further complicated things is the way different people handle it.

I followed the scheme set up by the groceries app for version 0.1 of my app. But as things got more complex, I came across this guide that re-defined how I looked at the binding model. The one laid out in that guide made more sense to me (I needed events to update in real time without waiting for a "submit" event), so I ended up re-writing a lot of the previous logic to reflect the new model for the next version.

Conclusions

All this to say, read lots and look around at different ways of using Nativescript before getting started. I started off with very little idea of what I was doing, and ended up spending a lot of time reworking things as my understanding of the framework was updated. That being said, it is a great framework, and I look forward to using it more in the future for other projects!