“gzip” für Webseiten

Um das Verhalten von “gzip / deflate” besser zu verstehen, möchte ich als erstes ganz kurz auf den Algorithmus hinter der Komprimierung eingehen. Dafür muss man zumindest zwei Grundlegende Theorien verstehen. Zum einen die sogenannte Huffman-Kodierung, dabei geht darum Text mit möglichst wenig Bits (0 || 1) zu übersetzen.

Es folgt ein einfaches Beispiel:

String: “im westen nichts neues”

Die Länge des Strings beträgt 22 Zeichen, was bei einem 4-Bit-Code (0000, 0001 …) eine Anzahl von 22 * 4 Bit = 88 Bit ergeben würde.

Berücksichtigt man jedoch die Häufigkeit der wiederkehrenden Zeichen, kann man für bestimmte Zeichen, welche oft im String vorkommen, kürzere Bit-Codes nutzen.

huff1

Als erstes Zählen wir die Anzahl der vorkommenden Zeichen. Die Zeichen welche die geringste Häufigkeit aufweisen werden anschließend als erstes miteinander Verknüpft und jeweils addiert.

huff4

Wie man bereits erkennt bekommen die Zeichen welche nicht so häufig auftreten längere Strecken und somit gleich auch längere Bit-Codes.

huff7

Wenn man alle Zweige verknüpft hat, entsteht daraus dann ein Binär-Baum, welcher von oben nach unten gelesen wird.

Die eindeutigen Bit-Codes sind nun z.B.: 00 für e, 100 für n, 1011 für t und so weiter. Nun benötigen wir nur noch 73 Bit anstatt 88 Bit, um den String binär darzustellen. ;)

Das zweite Prinzip hat auch mit Wiederholung von Zeichen zu tun. Die sogenannte “LZ77″ Kompression, welche wiederkehrende Muster in Strings erkennt und durch Referenzen von vorherigen Strings ersetzt.

Es Folgt ein einfaches Beispiel:

String: “Blah blah blah blah blah!”

 vvvvv     vvvvv     vvv
Blah blah blah blah blah!
      ^^^^^     ^^^^^

Wenn man nun die Wiederholung durch eine Referenz angibt, welche aus der Länge des Wortes (” blah” = 5) und Länge der Wiederholungen. (“lah blah blah blah” = 18). Daraus ergibt sich anschließend der folgende komprimierte Text.

Blah b(5,18)!

… aber nun endlich zum praktischen Teil! Es folgen ein paar Beispiele und Überlegungen im Zusammenhang mit Webseiten / Webservern.

1.) “gzip”, ABER weniger ist manchmal mehr

Bei kleinen Webseiten und schwachen V-Servern kann es vorkommen, dass die serverseitige Komprimierung im Gesamtkontext keinen Geschwindigkeitsvorteil bietet, da die Komprimierung ggf. mehr Overhead (Payload, CPU-Rechenzeit, Verzögerung der Auslieferung) mit sich bringt als es Vorteile (geringere Dateigröße) bietet. Zumal viele Dateien (Bilder, CSS, JS) nach dem ersten Seitenaufruf im Cache sind und nicht wieder vom Server ausgeliefert werden müssen. Gerade für mobile Geräte macht die Komprimierung jedoch fast immer Sinn, daher würde ich die Komprimierung immer aktivieren!

PS: hier noch ein Blog-Post zum Thema Webseiten Beschleunigen

moelleken_org-gzip
mit gzip
moelleken_org-nogzip
ohne gzip

GRÜN = Download
GELB = Wartet
BLAU = Verbindung zum / vom Server

Bei “nginx” gibt es zudem ein Modul (HttpGzipStaticModule) welches direkt vorkomprimierte Dateien ausliefert, anstatt diese bei Anfrage zu komprimieren. Jedoch muss man bisher selber dafür sorgen, dass eine entsprechende Datei mit dem selben Timestamp vorhanden ist. (z.B.: main.css & main.css.gz) Falls jemand hier eine Alternative oder ein einfaches Script zum erstellen der zu komprimierenden Dateien hat, meldet euch bitte bei mir oder einfach in den Kommentaren.

2.) “gzip”, ABER nicht für alles

Zunächst sollte man bereits komprimierte Dateien (z.B. JPEG, PNG, zip etc.) nicht noch zusätzlich via „gzip“ ausliefern, da die Dateigröße im schlimmsten Fall noch steigen kann oder zumindest wird für sehr wenig Dateigröße, sehr viel CPU-Zeit auf der Server (Komprimierung) und auf dem Client (Dekomprimierung) verbraucht.

gzip_images

Ich empfehle an dieser Stelle mal wieder die “.htaccess“-Datei vom HTML5-Boilerplate, welche bereits viele Einstellungen für den Apache-Webserver liefert. Außerdem gibt es dort auch eine optimierte Konfiguration “nginx.conf” für den nginx-Webserver.

3.) “gzip”, ABER nicht immer

Die “gzip”-Komprimierung kann Ihre Stärken bei größeren Dateien viel besser ausspielen, da wir ja bereits im theoretischen Teil gelernt haben, dass die Komprimierung auf Wiederholungen aufbaut und wenn wenig wiederkehrende Zeichen und Muster vorhanden sind lässt es sich schlecht komprimieren.

Beim “nginx”-Webserver kann man die minimale zu bearbeitende Dateigröße angeben, sodass eine 6 Byte große Datei mit dem Inhalt “foobar” bei schwacher „gzip“ nicht auf 40 Byte vergrößert wird.

gzip_small_file

4.) “gzip”, ABER nicht so hoch

Zudem sollte man nicht mit der höchsten Komprimierungsstufe komprimieren, da man pro Komprimierungsstufe immer weniger Erfolg bei immer mehr CPU-Zeit bekommt. Man sollte weniger stark komprimieren und dadurch Rechenleistung /-zeit einsparen, um die Webseite schneller ausliefern zu können.

gzip_level

test2_1.js.gz (schwache Komprimierung)
test2_2.js.gz (normale Komprimierung)
test2_3.js.gz (starke Komprimierung)

5.) „gzip“ + Minifizierung

Durch Minifizierung von CSS und JS kann man die Dateigröße ebenfalls reduzieren, auch wenn man nicht an die Dateigröße von komprimierten Dateien herankommt, außerdem sinkt der Erfolg der Komprimierung, da wir durch die Minifizierung bereits einige Wiederholungen minimiert haben.

Es folgt ein Beispiel mit „jquery.js / jquery.min.js“:

Zustand

Größe der Datei

gewonnene Größe durch die Komprimierung

nicht minifiziert + nicht komprimiert Datei

250 kB (¼ MB)

nicht minifiziert + schnelle Komprimierung

76,3 kB

173,7 kB

nicht minifiziert + normale Komprimierung

68,3 kB

181,7 kB

nicht minifiziert + hohe Komprimierung

68 kB

182 kB

minifiziert + nicht komprimiert Datei

82,3 kB

minifiziert + schnelle Komprimierung

30,8 kB

51,5 kB

6.) “gzip” + Komprimierung verbessern

Im Gegensatz zur Programmierung, wo man Wiederholungen vermeidet, sollte man im Frontend (HTML, CSS) gezielt Wiederholungen nutzen, um die Komprimierung zu optimieren. So zeigt  das folgende Beispiel wie man die Dateigröße durch die korrekte Positionierung von Attributen der HTML-Tags verbessern kann.

Zwei Dateien mit dem selben Dateigröße, nur die Reihenfolge der Attribute in der zweiten HTML-Dateien (“test1_2.html”) wurden nicht in der selben Reihenfolge angegeben.

html_order_3
test1_1.html
html_order_2
test1_2.html

html_order

Wie man in dem Bild erkennen kann, haben wir die Dateigröße der HTML-Datei um zirka 10% reduziert indem wir den Komprimierungsalgorithmus  bei der Arbeit unterstützen. ;)

Videos:

 

ShellShock – Sicherheitsproblem bei der Unix-Shell $(bash)

Alle alten Version der Unix-Shell “bash” enthalten eine kritische Sicherheitslücke (CVE-2014-6271), so dass man Befehle z.B. über CGI-Skripte oder via DHCP ausführen kann.  Ggf. benötigt nun dein Handy (z.B. CyanogenMod), dein Router oder deinen Mac / Linux / BSD und so weiter Software-Updates.

Teste dein System:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable
this is a test

Nachdem man die aktuellen Updates eingespielt hat (z.B. via aptitude) dann sollte die Ausgabe folgendermaßen aussehen.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

Technische Erklärung:

(http://seclists.org/oss-sec/2014/q3/650)
Das Problem ist, dass das man zwischen unterschiedlichen Bash-Instanzen Variablen und Funktionen teilen kann.

export foo='() { echo "bar" ; }'
bash -c 'foo'

Jede neue Bash-Instanz wird nun beim Start die Funktion “foo”  registrieren, so dass man diese Ausführen kann. Wenn man nun jedoch eine Funktion exportiert, führt die Bash den nächsten Befehl ebenfalls aus, da der String der “() {” nicht korrekt geparst wird. Damit können wir nun Befehle ausführen, indem wir bestimmte Strings (Funktionsdefinitionen) an z.B. ein CGI-Skript übergeben.

Links:

http://www.heise.de/newsticker/meldung/Bash-Luecke-ShellShock-ist-noch-nicht-ausgestanden-2403607.html

http://www.heise.de/newsticker/meldung/ShellShock-Standard-Unix-Shell-Bash-erlaubt-das-Ausfuehren-von-Schadcode-2403305.html

http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025

 

V-Server Problem bei Strato

Mein Virtueller Server von Strato hat diese Woche erhebliche Probleme. Angefangen hat dies bereites letzte Woche, daher habe ich am 22.06.2014 eine Support-Anfrage mit der Bitte um Prüfung geschrieben, jedoch bisher nur die Antwort erhalten, dass ein überlastetet Hostsystem ggf. zu den Problemen führt und dass dies momentan geprüft wird.

– Server-“Load”: > 10
– CPU-Auslastung : ~ 0%
– I/O-Auslastung: ~ 0%

——————————————

Reaktionszeit: 1/2 Min. für den SSH-Login  :-(

Daher kann es zwischenzeitlich auf dieser Webseite noch zu erheblichen Ladezeiten kommen, ich bitte dies zu entschuldigen. Wenn jemand einen guten Tipp für einen neuen Hoster hat oder andere Schlüsse aus den folgenden Screenshots ziehen kann, schreibt mir dies bitte per E-Mail “lars (at) moelleken.org” oder einfach direkt hier als Kommentar, vielen dank! Mfg Lars

 

server_vmstat

server_iotop

server_top

 

Falls jemand ebenfalls Performance-Probleme mit seinem Linux-Server hat, sollte man sich einmal folgenden aktualisierten Blog-Post anschauen:

-> Server-Analyse: http://suckup.de/linux/linux-server-analysieren/

 

UPDATE: 02.07.2014 15:59

Sehr geehrter Herr Moelleken,

ich möchte Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.

Sie hatten von Beeinträchtigungen bezüglich der Performance Ihres STRATO Virtual Server Linux berichtet.
Vorab bitte ich die Ihnen dadurch entstandenen Unannehmlichkeiten zu entschuldigen.

Erfreulicherweise kann ich Ihnen nun mitteilen, dass die Einschränkungen an Ihrem Server mittlerweile vollständig behoben wurden. Ihr Server ist damit wieder in vollständigem Umfang und mit gewohnter Performance zu erreichen.

Ich wünsche Ihnen weiterhin viel Erfolg mit Ihrem STRATO Server und stehe auch weiterhin bei Rückfragen für Sie bereit.

 

Multi-Platform Mobile Apps via Ionic

Ionic ist ein Frontend-Framework, mit welchem man via HTML5 / JavaScript und CSS native Apps bauen kann. Diese Apps können via “Apache Cordova” auf native Funktionen (Kamera, GPS, etc.) der Geräte zugreifen. Zudem wird Google’s JavaScript Framework “AnguarJS” genutzt und natürlich wird auch “SASS” unterstützt.

Vorbereitung

Man kann Multi-Platform Mobile Apps sowohl unter Windows, Linux oder Mac OS X entwickeln, jedoch ist die Vorbereitung unter Linux / Mac OS X um einiges einfacher.

Ich empfehle an dieser Stelle mal wieder die “.dotfiles” zu installieren.

cd ~ 
git clone https://github.com/voku/dotfiles.git 
cd dotfiles 
source bootstrap.sh

# Standard- & Webworker-Tools installieren

~/dotfiles/firstInstall.sh

Bei der Frage nach den “webworker tools”,  muss diese mit “y” beantwortet werden.

# Android SDK installieren

sudo ~/dotfiles/android_sdk_install.sh

# Java installieren

sudo add-apt-repository -y ppa:webupd8team/java
sudo aptitude update
sudo aptitude install oracle-java7-installer

# Ant installieren

sudo apt-get install ant

 

Nachdem die Installation komplett abgeschlossen ist, muss die “~/.extra”-Datei angepasst werden.

z.B.:

#!/bin/bash                                                                                                                                                                                                       

DEFAULT_USER="lars"
GIT_AUTHOR_NAME="Lars Moelleken"
GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
git config --global user.name "$GIT_AUTHOR_NAME"
GIT_AUTHOR_EMAIL="lars@moelleken.org"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
git config --global user.email "$GIT_AUTHOR_EMAIL"
git config --global push.default simple

# java - example
export JAVA_HOME=/usr/lib/jvm/java-7-oracle
export JDK_HOME=$JAVA_HOME
export JRE_HOME=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$PATH

# android - example
export ANDROID_SDK_ROOT=/usr/local/android-sdk/
#export ANDROID_NDK=/usr/local/android-ndk/
export ANDROID_HOME=$ANDROID_SDK_ROOT
export PATH=$ANDROID_SDK_ROOT/tools/:$ANDROID_SDK_ROOT/platform-tools/:$ANDROID_SDK_ROOT/build-tools/19.1.0/:$PATH

 

PS: bei Debian (sid) musste ich noch ein wenig nachhelfen, so dass die Android-SDK auch korrekt funktioniert:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install lib32z1 lib32stdc++6

 

Beispiel-App für Android erstellen

ionic start planet-ubuntuusers
cd planet-ubuntuusers
rm -rf www/
git clone https://github.com/voku/planet-ubuntuusers-app www
ionic platform android
ionic build android

Man kann die App nun im Browser (ionic serve), im Android Emulator (ionic emulate android) oder direkt auf seinem Android-Gerät (ionic run android) ausprobieren!!!

 

Links

Es folgen ein paar Links zur App / API / Dokumentation  und zum Beispiel-Quellcode

ANDOIRD APP-DOWNLOAD:
 http://suckup.de/planet-ubuntuusers-json/PlanetApp-debug.apk

QUELLCODE ZUR APP:
https://github.com/voku/planet-ubuntuusers-app

SCREENSHOT:
Planet App

JSON-API: 
http://suckup.de/planet-ubuntuusers-json/json.php

HTML-OUTPUT VIA TWIG:
http://suckup.de/planet-ubuntuusers-json/

QUELLCODE ZUR API:
https://github.com/voku/planet-ubuntuusers-json (in zirka 2 Minuten geschrieben & deployed -> composer is great!!!)

 

DOKUMENTATION:
https://docs.angularjs.org/
http://ionicframework.com/docs/
http://cordova.apache.org/

Kurztipp: lokalen offenen Port finden (bash)

Habe soeben folgende Funktionen zu meinen dotfiles hinzugefügt, um einen freien lokalen Port zu finden. Diese werden wiederum verwendet, um z.B. die “phpserver“-Funktion auszuführen.

# -------------------------------------------------------------------
# netstat_used_local_ports: get used tcp-ports
netstat_used_local_ports()
{
  netstat -atn | awk '{printf "%s\n%s\n", $4, $4}' | grep -oE '[0-9]*$' | sort -n | uniq
}

# -------------------------------------------------------------------
# netstat_free_local_port: get one free tcp-port
netstat_free_local_port()
{
  read lowerPort upperPort < /proc/sys/net/ipv4/ip_local_port_range
 
  # create a local array of used ports 
  local all_used_ports=($(netstat_used_local_ports))

  for port in $(seq $lowerPort $upperPort); do
    for used_port in "${all_used_ports[@]}"; do
      if [ $used_port -eq $port ]; then
        continue
      else
        echo $port
        return 0
      fi
    done
  done 
}

 

Web Development mit Linux (Video)

Im folgenden Video zeige ich kurz (~ 5 min.) wie meine Toolchain im Live-Betrieb aussieht, dabei nutze ich unter anderem Sublime Text, PHP, Twig, Grunt, Sass, Compass, LiveReload und ein paar Funktionen aus den “dofiles” (z.B. phpserver).

 

Wer den Beispiel-Code aus dem Video selber ausprobieren möchte, hier die Zusammenfassung:

sudo apt-get install git

cd ~
git clone https://github.com/voku/dotfiles/
cd dotfiles/
./firstInstall.sh
./bootstrap.sh
cd ~
vim ~/.extra #1

cd ~
mkdir Projects/
git clone https://github.com/voku/twig-wrapper-example/
cd twig-wrapper-example/
npm install
grunt watch

cd ~/Projects/twig-wrapper-example/
phpserver

#1 füge deine persönlichen Git-Einstellungen hier hinzu

 

Wer mehr Infos oder Erklärungen zu den hier verwendeten Tools haben möchte, sollte sich einmal folgende Videos anschauen: suckup.de/howto/html/moderner-build-development-workflow-via-bower-grunt-yeoman/

 

Sublime Text 3 – Ubuntu / Debian

Man kann über proprietäre Software denken was man will aber wenn Software wirklich gut ist und einem die Arbeit erleichtert / beschleunigt solle man sich diese zumindest einmal anschauen.

Installation

Es gibt unterschiedliche Wege Sublime Text zu installieren. Man kann das Paket direkt von der entsprechenden Webseite laden und mit folgendem Befehl installieren.

wget http://c758482.r82.cf2.rackcdn.com/sublime-text_build-3059_amd64.deb
sudo dpkg -i sublime-text_build-3059_amd64.deb

Info: dev-builds gibt es hier Oder man verwendet z.B. das Linux Mint Repository und installiert Sublime über den Paketmanager.

sudo echo "deb http://packages.linuxmint.com/ debian main import backport upstream romeo" >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get install sublime-text

 

Plugin-Manager hinzufügen

Auf der folgenden Webseite gibt es “den” Plugin-Manager für Sublime, welchen man auf jeden Fall installieren sollte: sublime.wbond.net/installation

mkdir ~/.config/sublime-text-3/Packages/Installed\ Packages
cd ~/.config/sublime-text-3/Packages/Installed\ Packages
wget https://sublime.wbond.net/Package%20Control.sublime-package

Nachdem man Sublime einmal neugestartet hat, findet man unter “Preferences -> Package Control” alle Befehle zum verwalten von Plugins.

 

Plugin Empfehlungen

– BracketHighlighter -> Bracket and tag highlighter for Sublime Text

– DocBlockr -> Simplifies writing DocBlock comments in Javascript, PHP, CoffeeScript, Actionscript, C & C++

Emmet -> Emmet (ex-Zen Coding) for Sublime Text

PHP-Twig -> A TextMate (and Sublime Text) bundle for Twig.

Sass -> Sass support for TextMate & Sublime Text 2

Git -> Plugin for some git integration into sublime text

– GitGutter -> A Sublime Text 2/3 plugin to see git diff in gutter

 

Links:

Sublime Text – Tips-Tricks-Shortcuts

– Best of Sublime Text 3 Features. Plugins and Settings

– Sublime Text – Keyboard-Shortcuts

– www.sublimetext.com/docs/3/

grep, ack, find, locate, sed, diff, wc …

An dieser Stelle wollte ich einmal notieren wie ich in der täglichen Arbeit mit z.B. “grep” oder “find” etc. umgehe, um möglichst schnell in Verzeichnissen und Dateien zu suchen oder Text zu ersetzten.

Ich werde hier nicht alle Möglichkeiten der entsprechenden Befehle nennen können, daher beschränke ich mich auf das, was ich wirklich verwende. Falls du dich weiter in der Thematik einlesen möchtest, empfehle ich gerne den “man”-Befehl oder wie andere es ausdrücken RTFM!

Falls dir die Begriffe tail, cat, less nicht viel sagen, dann klick hier!!!

 

grep: 

global regular expression print -> durchsucht Dateien und Verzeichnisse via RegEx bzw. nach Strings

Kurzform Langform Beschreibung
-H
--with-filename
gibt den Dateinamen vor jedem Treffer aus.
-i
--ignore-case
unterscheide nicht zwischen Groß- und Kleinschreibung.
-n
--line-number
gibt die Zeilennummer vor jedem Treffer aus.
-R
-r
--recursive
liest alle Dateien unter jedem Verzeichnis rekursiv.
-v
--invert-match
Invertiert die Suche und liefert alle Zeilen die nicht auf das gesuchte Muster passen.

z.B.:

grep -rHn test ~/php/

-> sucht im Verzeichnis “php”, welches sich wiederum im Home-Verzeichnis [~] befindet nach dem String “test”

PS: hier der selbe Befehl, jedoch eingeschränkt auf php-Dateien

grep -Hn test ~/php/**/*.php

Info: wenn man “git” im Einsatz hat, sollte man “git grep” verwenden ;)

 

ack:

Ack hat die selbe Aufgabe wie “grep” ist jedoch auf Entwickler zugeschnitten, so sucht “ack” im Standardmäßig rekursiv, ignoriert Binärdaten und Verzeichnisse von Versionkontrollsystemen (.svn, .git, etc.)

PS: unter Debian / Ubuntu findet man das entsprechende Paket unter “ack-grep”

 

find:

ist bei der Suche nach Dateien behilflich (“Alles ist eine Datei”)

Suchkriterien für find
Kriterium Beschreibung
-name Datei
Es wird nach Dateien mit dem Namen “Datei” gesucht. Sollen bei der Suche Platzhalter Verwendung finden, so muss der ganze Ausdruck in Anführungszeichen gestellt werden, zum Beispiel

-name "*.txt"
-iname Datei
Es wird nach Dateien mit dem Namen “Datei” – ohne Beachtung der Groß und Kleinschreibung – gesucht.
-type f
Es wird nur nach regulären Dateien gesucht.
-type d
Es wird nur nach Verzeichnissen gesucht.
find -size +10M -20M -exec ls -lah {} \;

-> sucht alle Dateien welche eine Dateigröße zwischen 10 – 20 MB haben und zeigt diese an

WARNING: der “exec”-Parameter kann auch für jeden anderen Befehl auf die Ergebnismenge von “find” ausführen, dabei sollte man jedoch bei dem “rm”-Befehl besonders vorsichtig sein. Und ggf. kann man sich safe-rm anschauen. ;)

PS: hier sind noch ein paar Beispiel

 

locate:

“sudo updatedb” nicht vergessen und schon kann man sehr schnell nach Dateien suchen, da die Dateien nicht im Filesystem, sondern in einer Datenbank (updatedb) gesucht werden.

z.B.:

locate Download | grep home

 

sed:

Es handelt sich hier um einen “nicht-interaktiver Texteditor” was eigentlich nur bedeutet, dass man damit String verarbeite kann. Zum Bespiel kann man ein bestimmtes Wort in einer Datei durch ein anderes ersetzten.

https://github.com/voku/dotfiles/blob/master/.functions

# WARNING -> replace: changes multiple files at once
replace()
{
  if [ $3 ]; then
    find $1 -type f -exec sed -i 's/$2/$3/g' {} \;
  else
    echo "Missing argument"
  fi
}
replace *.php alt neu

-> dieser Befehl such im aktuellen (+ Unterverzeichnisse) nach Dateien, welche auf “.php” enden und ersetzt darin “alt” gegen “neu”

PS: hier findet man ein paar nützliche Beispiele

Dabei ist besonders praktisch, dass man diese Funktionalität auch im “vim” verwenden kann indem man z.B. folgendes eingibt …

 :%s/alt/neu/g

 

diff:

Wie der Name schon vermuten lässt, kann man hiermit Dateien vergleichen. z.B.:

diff -u --ignore-all-space -r old/ new/

-> vergleicht alle Dateien rekursiv (-r) vom Verzeichnis “old/” und “new/” und ignoriert dabei Änderungen vom Leerräumen z.B. Leerzeichen oder Zeilenumbrüche (\r <-> \r\n)

Info: wenn man “git” im Einsatz hat, sollte man “git diff” verwenden ;)

 

wc:

word count kann Wörtern, Zeichen und Bytes (man ahnt es bereits) zählen. z.B.:

cat /proc/cpuinfo | grep processor | wc -l

-> zählt die Anzahl der CPU-Kerne

 

Quellen:
http://beyondgrep.com/ – ack
http://wiki.ubuntuusers.de/grep
http://wiki.ubuntuusers.de/find
http://wiki.ubuntuusers.de/locate
http://wiki.ubuntuusers.de/wc
http://suckup.de/linux/find-linux/
http://suckup.de/linux/streameditor-sed/

Kurztipp: RegEx für die Paketsuche

Habe soeben einen älteren Blog-Post aktualisiert und einen kleinen Tipp hinzugefügt, welchen ich hier an zwei Beispielen zeigen möchte: suckup.de/linux/ubuntu/aptitude-dpkg/

sudo aptitude search "^php5-[a-cA-C]+"

-> sucht alle Pakete welche mit “php5-” anfangen und darauf “a”, “b oder “c” in beliebiger Häufigkeit folgen

sudo aptitude search "(^bash|^git).*completion"

-> sucht Pakete welche entweder mit “bash” oder mit “git” anfangen gefolgt von beliebigen (auch beliebige Anzahl) von Zeichen, gefolgt von dem String “completion”

Die RegEx-Funktionalität funktioniert sowohl bei “apt-cache”, “apt-get” als auch bei “aptitude” und auch bei anderen Befehlen wie z.B.: “remove”, “install”, “search”, “purge” etc. Bei meinen Tests hat dies jedoch mit “aptitude” am besten funktioniert, da hier nur nach den Paketnamen gesucht wird, falls man jedoch nicht genau weiß wonach man eigentlich sucht, dann sollte man es wohl mit “apt-cache” versuchen.

PS: wer sich RegEx noch nicht angeschaut hat, der sollte auch mal die Links in den Quellen anklicken, da man dies z.B. in so gut wie jeder Programmiersprache, in der Shell oder ansatzweise selbst bei der Google-Suche nutzen kann. Wer mehr über Tricks in der Google-Suche erfahren möchte, klickt hier! ;)

Quellen:
https://www.debian.org/doc/manuals/debian-reference/ch02.de.html#_browsing_with_the_regex_matching
http://regex101.com/
http://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck

my dotfiles

Habe meine dotfiles (Dateien im Home-Verzeichnis, welche mit einem “.” beginnen) mit anderen Quellen angereichert und diese auf github veröffentlicht. Wer möchte kann diese Einstellungen, Aliase, Funktionen für die “Linux-Shell” verwenden oder auch verbessern, indem man einen entsprechenden Fork von dem Projekt erstellt.

dotfiles_vimdotfiles

https://github.com/voku/dotfiles

Installation:

cd ~ && git clone https://github.com/voku/dotfiles.git && cd dotfiles && ./bootstrap.sh

… wenn gewünscht kann man mit diesem kleinen Skript entsprechende ggf. benötigte Pakete nachinstallieren:

./firstInstall.sh

Update:

./bootstrap.sh

Einstellungen:

Die Datei “~/.config_dotfiles” beinhaltet einige Einstellungen für die entsprechenden dotfiles. Wenn diese Datei nicht existiert wird diese automatisch beim ausführen der “bootstrap.sh”-Datei erzeugt.

z.B.: “cat ~/.extra”

CONFIG_DEFAULT_USER="lars"
CONFIG_TMUX=false
CONFIG_ZSH_PLUGINS="(git bower composer ruby bundler gem)"
CONFIG_ZSH_THEME="voku"
CONFIG_BASH_THEME="voku"
CONFIG_CHARSET_UTF8=true
CONFIG_LANG="en_US"

Plugins:

Die Plugins sind von “bash-it“, “oh-my-zsh” und eigenen eigenen Anpassungen zusammengefügt. Außerdem wurden Plugins welche all­ge­mein­gül­tig sind in die globalen “.aliases” und “.functions” ausgelagert.

ZSH (Z-SHELL): https://github.com/revans/bash-it/tree/master/plugins/

BASH: https://github.com/revans/bash-it/tree/master/plugins/available

Anpassungen:

Wenn die Datei “~/.extra” existiert, wird diese zusammen mit den anderen Dateien verarbeitet. Man kann diese nutzen, um benutzerdefinierte Befehle ausführen zu lassen.

z.B.: “cat ~/.extra”

GIT_AUTHOR_NAME="Lars Moelleken"
GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
git config --global user.name "$GIT_AUTHOR_NAME"
GIT_AUTHOR_EMAIL="lars@moelleken.org"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
git config --global user.email "$GIT_AUTHOR_EMAIL"
git config --global push.default simple

 

Erklärungen / Quellen:

http://suckup.de/linux/bashrc/
http://wiki.ubuntuusers.de/Bash/bashrc
http://suckup.de/linux/vi-howto/
http://vim.wikia.com/wiki/Example_vimrc
http://dotfiles.org/