Creating Tests – As long as they are automated

testing,

I have been often asked about testing, how something could be tested automatically, how something could be tested at all. Especially if there is/was no testing framework. My answer has been always the same:

It doesn’t matter. As long the tests are autmated.

Testing frameworks have been created over time. They have not been there from the beginning. Eventually, there is no test framework for your problem yet. However, this does not mean you can’t test.

An error was reported in my EIP-PlantUML side project. After some analysis, I figured out it was caused by a syntax issue within a string in a definition file. The problem here, you see the particular error only once the result has been rendered as an image. How to test this?

I simply wrote a Bash script checking the definitions instead. That’s all. It passes with the exit code 0 or 1 if the test fails. That way I will be able to integrate it in a test suite later one ,even if I don’t know how this will look right now.

The test script itself is rather simple using grep in a shell script. 

#!/bin/bash
Red=$'\e[1;31m'
Green=$'\e[1;32m'
Clear=$'\e[0m'

count=$(grep 'r_label' -c ../EIP_Elements.puml)

if [ "$count" -eq "0" ] ; then
    echo "$Green PASSED:$Clear No issues detected."
    exit 0
else
    echo "$Red FAILED:$Clear Issues detected."
    grep 'r_label' -n ../EIP_Elements.puml
    exit 1
fi

fzf – Command-line Fuzzy Finder on macOS X

apple, , , , 2 Comments

If you master your Terminal it always looks like you are a superhero. Therefore, I always try to present a lot using terminal during my lecture, just to provide some smoke and mirrors.

However, I am far away from mastering Terminal truly. Therefore, it comes in handy that one of my students pointed me to reverse-i-search which is available on Terminal.

Wich this reverse lookup you can search through previous commands used in Terminal before. While this is an awesome feature you can activate by control-r on macOS, it does not allow you to search for similar commands used before. It always shows just exact matches of what you typed.

reverse-i-search on macOS

To search through similar typed commands, you can use fzf, a command-line fuzzy finder available at GitHub.

It’s an interactive Unix filter for command-line that can be used with any list; files, command history, processes, hostnames, bookmarks, git commits, etc.

Installing on macOS using Homebrew

For your convenience you can install fzf using Homebrew using the command 

brew install fzf

For me, the bash integration was not available after the installation. After some investigation (I might haven’t read the instruction well enough), I realized the installation script needs to be run:

/usr/local/opt/fzf/install

Eventually, the installation routines put [ -f ~/.fzf.bash ] && source ~/.fzf.bash into .bashrc. I run into this issue some time before. Reading through this article on Scripting OS X might give you an idea why it does not run.

When you open a terminal application, it does not ask for login. You will just get a command prompt. In other versions of Unix or Linux, this will not run the .bash_profile but a different file .bashrc. The underlying idea is that the .bash_profile should be run only once when you login, and the .bashrc for every new interactive shell.

However, Terminal.app on macOS, does not follow this convention. When Terminal.app opens a new window, it will run .bash_profile. Not, as users familiar with other Unix systems would expect, .bashrc.

Moving the line mentioned above into .bash_profile and deleting .bashrc eventually solved the issue. After restarting Terminal the key bindings CTRL-R and CTRL-T have been available as expected.

fzf command-line fuzzy search

With this little trick the installations of fzf works quite well on macOS X Mojave.

tl;dr

Use reverse-i-search by pressing control-r on macOS to search previous commands typed in Terminal. In addition, you can use fzf, a command-line fuzzy finder to find similar commands and all other kinds of stuff.

To install run

  • brew install fzf
  • /usr/local/opt/fzf/install
  • copy [ -f ~/.fzf.bash ] && source ~/.fzf.bash from .bashrc into ~/.bash_profile (and remove .bashrc if not needed) or source .basrc from .bash_profile

Link: https://github.com/junegunn/fzf

Check and Fix the Shellshock Exploit on Mac OS X

apple, ,

Since I switched to Mac in 2011, I do not keep that much track of vulnerabilities as I did running Windows as my main system. However, the recently announces Shellshock exploit got my attention. As Apple has no patch in place by today, I went for a manual path of the bash shell. Only precondition is Apple’s Xcode being installed on your system.

First, checking whether your  system is vulnerable, you simply need the following bash script being run:

env x='() { :;}; echo not' bash -c 'echo safe'

In my case, unfortunately, I got a

not
safe

on my shell, running Mac OS X 10.9.4. Checking the version is simple done as following:

bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

In case you passed the check, you should run a second one, as since Thursday, there is a second attack vector knwon

env X='(){(a)=>\' bash -c "echo date"; cat echo; rm -f echo

The good news, not vulnerability from this vector.

date
cat: echo: No such file or directory

In case one would get the current date and time, there would be vulnerability, too.

As there is no patch from Apple right now, there is an possibility to build an update manually from the GNU repositories.

mkdir bash-fix
cd bash-fix
curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
cd bash-92/bash-3.2
curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0
cd ..
sudo xcodebuild

In case you are vulnerable to the second vector, there is a another path to be applied:

mv build/bash.build/Release/bash.build/DerivedSources/y.tab.* bash-3.2/
cd bash-3.2
curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053 | patch -p0
cd ..
sudo xcodebuild

By running

bash-fix/bash-92/build/release/bash --version 
bash-fix/bash-92/build/release/sh --version

you should be able to verify the version of the fix.

GNU bash, version 3.2.52(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Before replacing the old version, I backup the original bits.

sudo cp /bin/bash /bin/bash.3.2.51.bak
sudo cp /bin/sh /bin/sh.3.2.51.bak

Now you can replace the original ones by

sudo cp bash-fix/bash-92/build/Release/bash /bin
sudo cp bash-fix/bash-92/build/Release/sh /bin

Once this is done, you can check for the exploit again

env x='() { :;}; echo not' bash -c 'echo safe'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
safe

Once verified, you can get rid of the bash-fix folder and your system should be safe from this exploit.