• Individualize the Bash

    If you work a lot in the BaSh, you will appreciate the ability to create own preferences and shortcuts. Those will make the terminal an even more powerful tool.

    You can edit you personal settings of the Bash in one of two files (depending on your system) within your home-directory. The .bashrc or the .bash_profile. The leading dot means the files are hidden. To show hidden files, you to tell ls to show all files:

    cd ~
    ls -a

    The first line changes into your home-directory (in most cases you can also just type cd). The second line shows all files, including hidden ones.

    You can edit the Bash-profile-file in every texteditor you like.


    An alias is a kind of shortcut. With an alias you can create your own bash-commands. Let's start with a simple example: Imagine you want to show all files in a directory as a list over and over. You would then enter the following:

    ls -lah

    ls to list, -l to get a detailed list, -a to also show hidden files, -h to show the information in a human readable format. Of course you could enter this command alle the time, but also could create an alias.

    You are free to add you alias-definition anywhere in the bash-profile-file. I prefer to add them on top. So, let's create our alias by adding the following line:

    alias ll='ls -lah'

    That's it. We just created the alias ll which will execute our special ls-command we used above.

    Don't worry, if you saved your bash-profile but the alias isn't working. The .bashrc or the .bash_profile are only parsed once when your login-session is initialized. So you have to quit your terminal-application and start it again or, if you are working directly on the console, you have to logout an -in again.

    Hint I don't know if this works on every system, but you may also use the reset command to initalize a new session.

    You can now add as many alias-definitions as you like. Everything you can do in the bash can be an alias. But watch out! Avoid using alias-names which may already be bash-commands to avoid trouble.


    By the way. If you are working git a lot in your terminal, you can define special git-alias, too! You can read here, how it works and what to do.

    Individualize the bash-prompt

    You can upgrade your bash-prompt with a lot of usefull information. I prefer a minimalistic approach. Especially on my desktop-computer. I am always logged in a the same user and I don't need the hostname to be shown all the time. So I modified my bash-prompt to look like so:

    It only shows the current directory I am in. Let's change the directory to make it a bit more visual:

    I am in the directory _PROJECTS. As you can see only the current directory is shown not the whole path. That's because I want my prompt to be as short as possible.
    Because I am working a lot with git, I extended the prompt to show the actual branch as soon as I am in a git repository:

    You can individualize you prompt, by adding (in my case) the following line to the bottom of you bash-profile-file:

    PS1="\[\033[1;33m\]\W\[\033[0m\] \[\033[1;32m\]\[\$(git_prompt_info)\]\[\033[0m\]$ "

    To get the git-part up and running, you need to add a special function to your bash-profile. Btw. there is a nice webtool to create your own prompt.

    Search your bash-history

    If you want to look for already used commands you can easily do so by hitting ctrl+R and start typing the command. You will then get suggestions based on already used commands. If you like the search through the history chronologically you can use this snippet.

    More ideas?

    You have some more ideas or hints on how to make your bash-life more comfortable? Post a comment or ping me on twitter.

    Read full post
  • My top 10 Sublime Text 3 plugins

    I don't know how I survived before knowing Sublime Text. For me, there is no better editor. It's slim, fast and incredibly adaptable. Not at least because of the thousands of packages available. These ones are my favorites

    Sublime CodeIntel

    The holy grail for Sublime Text. Autocomplete of functions, methods and variables spread over files. Direct jumps to definitions and function call tooltips. A sublime text project is required for that.

    Get the plugin


    Emmet was known as "zencoding" before. It allows you, to use abbreviations to create lightning fast HTML- or CSS-Code. A line like:


    will create the following HTML-Code:

    <div id="myID“>
        <ul class="classname">

    Read more about emmet


    Whenever you define a color in your css-file, GutterColor will show this color right next to the linenumber. I am eagerly awaiting support for sass and less variables.

    Get the plugin


    I already wrote about my markdown-setup here. The Plugin offers some extended markdown-functions and a nice style.

    Get the plugin


    Because I like using scss/compass, I installed this Plugin to get the syntax-highlighting.

    Get the plugin


    I use Handlebars as a template-engine for a lot of my JavaScript-projects. To get propper highlighting I use this Plugin.

    Get the plugin


    I think I do not need to tell you a lot about this. This plugin offers a lot of snippets which will help you working with jQuery.

    Get the plugin


    To document my sourcecode, I use DocBlockr (yet). If you type in the shortcut for DocBlockr right before a function, it will create a dummy-documentation-comment and fill in variables needed by the function automaticly.

    Get the plugin


    There are always little code-snippets, which can be used in different projects. To store those, I use Gists on GitHub. Gists can be private or public available. This plugin helps you creating and receiving them. It also allows you to search through plubic gists.

    Get the plugin


    The theme of my choice is PreDown. You have to take a look at it, because it's hard to describe.

    Get the theme


    All packages can be installed via Package Control. You can read here how to do so.

    And you?

    You also use sublime text and know some really good plugins? Post your list in the comments or send me a link to your blogpost. I will link them here.

    Read full post
  • Automate your webhook-configuration

    I thought about how to optimize my project-creation-progress and wrote a little script for that.

    In my article about GitLab-Webhooks, I wrote about how to simplify your deployprocess with a few simple steps. If someone pushes to a GitLab-project, a webhook will be run which updates your stage- or production-server.

    In my solution I use a PHP-script, which reads a config-file to determine if the project which runs the webhook is a known one and if so, which branch has to be deployed.

    I still like that solution, but I do not like, that I

    1. have to create the base-directory for a new project and set needed permissions all the time
    2. have to modify the deploy-configuration by myself.

    Because, in my case, the deploy-config is the same most of the time (of course the path to and the name of the project differs), I tried to automate these steps.

    addProject Bash-Script

    So I wrote a little Bash-script, which helps me.

    • It creates the base-directory of the project in the document-root.
    • It modifies the deploy-config with standard-parameters and adds the correct path and project-title.

    To prevent doublications and make sure the script does not overwrite exisiting files, the script checks if the new project already exists.

    cd /var/www/
    if [ ! -d "$1" ]; then
        mkdir -p "$1/logs"
        chown YOURUSERNAME:www-data $1-$2
        chmod -R 775 $1
        cd /var/www/DEPLOYSCRIPTDIRECTORX/
        head -n -2 deploy.json > temp.txt ; mv temp.txt deploy.json
        printf "\t},\n\t\"$1\": {\n\t\t\"path\":\t\t\"/var/www/$1\",\n\t\t\"limit\":\t\"master\"\n\t}\n}" >> deploy.json
        echo Project already exists!

    How to run

    To execute the script, you type:
    /path/to/script.sh projectTitle

    In my script there is a second parameter, which is a running number of the job. I want that to be part of the directory-name. I didn't include it in my sample here, but you can add more parameters by using the vars $2, $3, $4 …

    The command above will create the directory projectTitle in /var/www.

    How it works

    First the script changes the current directory to the apache-document-root, that's /var/www for me, it may also be /srv/http for example. You should modify that for your needs in line 3 and 10 (I modified it a bit, because my client-works are in a subdirectory).

    After that the script checks if the project-directory does exist. If so it will exit with a warning. If not, it will continue.

    The directory will be created and the needed permissions will be set. The group of the directory will be set to www-data and the group gets write-access, so the deploy-script can write into the directory later.
    If the deploy-script or your webserver runs as another user, you may want to change the group-name.

    Then the script changes the directory of your deploy-configuration to extend it. First it will strip off the last two lines, which are the closing brackets of the json and of the last project.
    Then the last projects gets its bracket back appended by a comma (so the next entry can follow).
    After that the new entry will be written, the projectname and the path will be set. As default, the master-branch will be set for automatic deployment. If you want all branches to be deployed, you can change master to null or whatever branch you want to by deployed.
    Finaly the closing bracket of the json is written.

    So, with that the project ist set up and can be used. I put my script in my GitHub-Repository, hope it helps. If you have tips our questions feel free to comment below.

    Read full post
  • Bilingual Kirby

    Maybe some of you have noticed, I am trying to write bilingual. So I wrote some helpers for that.

    My last posts here could be read in english (surprise!), too. Although my written english is a bit rusty, I will keep translating my posts in the future and will try to translate the older ones step by step.

    I am not that enthusiastic by the possibilites which come with Kirby, but it works, as you can see. I wrote a little snippet to switch languages and added a translation-detection I am using in my blog-header.

    The problem is, Kirby will show the german text under a /en/-URL if there is no translated file available. I don't want that. You should not be able to click on the link for a translation which isn't there. So I modified the default-code for switching languages a little bit.

    So it works better (for me)

    First I try to figure out, which template is used by the current article. The templatename matches the first part of the filename. With that information I can look for a translation of the text. If a translation is available the language-switch-link is clickable, if not, the link is not clickable.

    Have a look:

    <?php foreach(c::get('lang.available') as $lang) : ?>
        <?php if($lang != c::get('lang.current')) : ?>
            <?php if($page->files()->find($page->template().'.'.$lang.'.md')) : ?>

    To prevent manual modifications of the URL from "de" to "en" I am using a translation-detection in the header-file. If I would not do so, you could change "de" to "en" in the URL, but you would see the german text, if no translation is available. And I don't want you (and searchengines) to do so.

        $lang = c::get('lang.current');
        $other = ($lang == 'de') ? 'en' : 'de';
        $template = $page->template();
        if($page->files()->find($template.'.'.$lang.'.md') == NULL) {
            header ('HTTP/1.1 303 See Other');
            header('Location: '.$page->url($other));

    First I look which language is choosen and see what its counterpart is. Then again the test if a translation is available. If not, I am redirecting to the german version (which changes the URL).

    I am not sure, if the 303-header is really correct, but it semed the best solution for me. This whole solution only works, if you are only bilingual. If you would like to support more than two languages you need to modify it.

    My snippets can, as always, be found at GitHub.

    Read full post
  • GitLab Webhooks

    Some versions ago, I think it was version 5.2, GitLab introduced Webhooks. I didn't like them at first but that changed since I found a great PHP-script, which I slightly modified.

    I am a big fan of GitLab (even though the updateprocedures are pure horror) and I am using it for all the jobs and projects I am working on. I think GitLab is a great alternative to GitHub.

    To get a smoothly running workflow and because I don't want to copy or pull files after pushing them to see the Changes on the websites, I use hooks.


    Hooks are little scripts, run at a certain time. For example when changes where pushed to a repository. You can use these hooks to update a website automagically after a push, or take a stupid looking picture of yourself with every commit.


    Now there are those webhooks. Principle they work the same as normal hooks. With every push a script is run. Until now, in my case, those scripts where simple BaSh-scripts. But those webhooks are working a bit differnt. You don't create a BaSh-script for every repository, you just tell GitLab what URL to open.
    With every push, this URL will be opened and the relevant data will be submitted as JSON-string.

    The big advantage is, you can execute different scripts by adding additional URLs.
    The disadvantage is, you cannot use BaSh-Scripts anymore, because those normally aren't reachable via an URL.

    The solution

    So I looked around on the web and found a PHP-Script which seems to fit my needs.
    The script evaluate the JSON and updates the corresponding branch. It even creates a folder for branches which didn't exist before.

    So, whenever I push something to my master-branch, the URL (PHP-script) will be opened and the directory "master" will be updated or created if it doesn't exist.

    So far, so good.

    There are two things, I didn't like.

    1. I have to copy the script for every repository and edit the included Path and URL to the repository.
    2. It might happen, that I am working on branches, which do not need to be transfered to the webserver. Particularly when working on bigger projects there might be various branches which are merged from time to time, but must not be available on the webserver.

    My modified solution

    So I took the script and thought about, how to improve it. And this is how my solution works:

    The PHP-script has to be copied to the server on which the webserver is running. I use a vhost for it, so I have a nice domain for that. The script has to exist once only.

    Also I created a config-file. A simple JSON-file which has the following structure:

        "repoName": {
            "path": "/path/to/folder",
            "limit": null

    The name of the repository as to be the exact name as set up in GitLab, because the name will be submitted within the GitLab-JSON and can be referenced that way.

    path is the directory in which the subdirectories for each branch will be created. In most cases this will be within document-root.

    limit can be null, then all branches will be cloned and updated. If you whish just to update certain branches, you can give limit a comma-separated list of branch-names.

    "limit": "master,testing"

    You do that for each repository.

    In this way you just have to maintain two files. The PHP and the config-file. If you make changes to the PHP you do not have to make those changes several times.


    To get the script running, some basic steps have to be done before (creating deploy-key etc.). I will not explain those here, because they are explained in the blogpost of the original script very well.

    Attention meridimus was so nice to give us a tip in the comments. In step 7 of the original article, the directory also needs the execution-flag so the known_hosts file can be created. Do it like so:

    $ sudo chmod -R 0600 /var/www/.ssh
    $ sudo chmod 0700 /var/www/.ssh
    $ sudo chown -R www-data:www-data /var/www/.ssh


    if you are interessted in the script, you can take a look at GitHub.


    I wrote another article about how to automate your deploy-configuration with a simple bash-script.

    Read full post