Hey du, ich hab da mal 'nen Werkzeug gebaut.

Und was für eins?

Eins für Reguläre Ausdrück.

Kuhl.

Jau, ich bin wieder online und das erste worüber ich schreibe ist 'nen Werkezug. Is' halt iwie einfacher als über anderes zu schrieben.

Gebaut habe ich das Werkzeug, ganz einfach, weil mir bisher keins grafisches¹ bekannt ist das das kann, was ich will: Muster in Zeichenketten suchen und benutzerdefiniert anzeigen. Simpel.

Wie das Präfix schon andeutet habe ich das Werkzeug in Java geschrieben. Die Nutzeroberfläche habe ich mit SWT umgesetzt, mithilfe meiner Java Werkzeuge.

Aufgebaut habe ich die Oberfläche erst mal in zwei Spalten. Links die Eingabe für die Zeichenkette als mehrzeiliges Textfeld und rechts in der ersten Zeile die Mustereingabe als einzeiliges Textfeld, eine Checkbox um die benutzerdefinierte Ausgabe zu aktivieren und ein Textfeld für das Muster der Ausgabe. Darunter ein mehrzeilige Textfeld in dem dann alle Funde (benutzerdefiniert) ausgegeben werden. Darunter wiederum eine Checkbox um die Mustereingabe uninterpretiert² zu nutzen.

[caption id="attachment_1518" align="alignright" width="300"] Screenshot jStringTool[/caption]

Funktion

• Muster werden als reguläre Ausdrücke angegeben.
  • bei ungültigen Ausdrücken wird das Muster rot
• Funde werden rot hervorgehoben
• die benutzerdefinierte Ausgabe ersetzt alle $n Ausdrücke durch die dazugehörige Fundgruppe, %n kann für Zeilenumbrüche genutzt werden.

Zukunft

• dynamisches speichern aller Daten
• Manipulation einzelner Fundgruppen (teilen, zusammenfügen, ersetzen)
• Flags für RegEx
• dynamische Größe der Textfelder

Links

• Quellcode auf GitHub criztovyl/jStringTool
• v0.1 für 64bit Windows (x86_64): jStringTool v0.1

---

¹ im Sinne einer grafischen Nutzeroberfläche

² Programmiererenglisch "quoted"

Derzeit gibt es im Internet viele verschiedene (kleine) Wikis, die sich alle mit anderen Themen beschäftigen und sich meistens auf ein spezielles Fachgebiet (eine Domäne) beschränken. Meine Idee war, meinem Plattformgedanken, den ich noch niederschreiben muss, folgend, dass jedes Wiki einerseits ein Zugangspunkt zu einer großen, dezentralen Datenbank ist, die mensch dann, auf die Domäne des Wikis bezogen, durchsuchen kann und andererseits einen Teil dieser Datenbank stellt und in diesem die Domäne behandelt. Die Suche in einem Wiki würde dann vorzugsweise auf Seiten im Zugangspunkt-Wiki verweisen und erst nachrangig auf die anderer Wikis bzw. (globale) Begriffserklärungsseiten, wobei die Rangfolge der verschiedenen Wikis konfigurierbar sein soll.

Ein Beispiel:

Gehen wir mal von einem Wiki zu einem fiktiven Spiel aus, nennen wir es "Öllp". Die Datenbank des Öllp-Wiki würde dann nur aus Artikeln bestehen, die sich in dieser Domäne befinden, bspw. spielinterne Gegenstände, die Geschichte im Spiel, die Geschichte des Spiels und Seiten zu den Entwicklern, da diese größtenteils in anderen Domänen irrelevant wären. Es könnte aber bspw. die Seite zum Spiel selbst in einen Wiki zu Spielen zu finden sein. Nehmen wir weiterhin an, in dem Wiki existiert eine Seite die sich mit einem Brennstoff innerhalb des Spieles beschäftigt und über den Brennwert des Stoffe informiert. Wenn der Nutzer/die Nutzerin dann nach "Brennwert" sucht und keine Seite in Öllp-Wiki zu finden ist, erscheint eine Begriffserklärungsseite, die die Seiten anderer Wikis auflistet, die diesen Namen haben, oder er/sie wird direkt auf eine der Seiten weitergeleitet, die er/sie als präferiert angeben hat, bspw. die Wikipedia.

Das war's auch schon, vllt greif' ich den Gedanken ja später nochmal auf. Als nächstes schreibe ich dann einen Artikel über T9 für Smartphones.

Currently I'm doing concept coding for using the repositories. The initial plan was to use JSON files but now I will use a simpler file format because using JSON Bash-only is unnecessary hard. The format will be a line and white-space orientated one, where a line is a script definition containing two parts, separated by a white space, first the name and second the (relative) path to the script file.

So now the file format looks like this:

script1 path/to/script.sh
script2 path/to/script.sh

timf

timf ist meine Idee einer Internetplattform, wobei sich die Idee derzeit noch konstant weiterentwickelt. timf steht für "Thanks, I am fine.".

DaFeed

DaFeed (engl. Aussprache), ist meine Idee, wie ein Stream in einem sozialen Netzwerk aufgebaut werden sein sollte. Um die Idee zu beschrieben, werde ich ihn mit einem Facebook-Stream vergleichen, wie ich ihn als informierter Nicht-Facebook-Nutzer wahrnehme an der Seite jeweils eine Visualisierung dazu (zum Vergößern auf das Bild klicken).

[caption id="attachment_1455" align="alignleft" width="111"] Facebook Stream (CC BY-SA 4.0)[/caption]

Bei Facebook gibt es eine riesige Masse an Elementen, die in den Nutzerstream möchten. Nicht alle diese Elemente kommen auch in den Sream, da Facebook sie anhand (geheimer) Kriterien filtert. Es gibt aber die Möglichkeit, auf jeden Fall im Stream aufzutauchen, aber nur gegen Bezahlung. Bei Facebook wird das, sehr treffend, "Bewerben" genannt. Da Facebook von den Einnahmen aus diesen Geschäften lebt, haben sie ein Interesse an einer Filterblase, um möglichst viele andere Nutzer dazu zu bewegen, ihre Elemente (Beiträge) zu bewerben.

[caption id="attachment_1456" align="alignright" width="266"] timf: DaFeed Stream/Feed (CC BY-SA 4.0)[/caption]

Ich möchte mit timf: DaFeed einen anderen Weg gehen. Mir ist bewusst, das alle Element in einem ungefilterten Stream zu einem unübersichtlichen chaotischen Stream führen würden, daher wird auch DaFeed Elemente filtern. Dies wird aber so stattfinden, das der Nutzer mehrere Kategorien hat, anhand derer er seinen Stream filtern kann, bspw. Freunde, Familie, Arbeit, Unterhaltung, usw., und somit einen Feed erhält, der dann nochmals durch einen anderen Algorithmus gefiltert werden kann, der durch den Nutzer sowohl einsehbar und konfigurierbar als auch selbst erstellbar ist.

A Core of my .bashrc.d Concept are one the one hand the repositories where you can download other users scripts and extend your Bash in this way and on the other hand that it everything should be a bash-only. To use a repository the script requires to access the files in it. Downloading via HTTP work bash-only, but HTTPS sadly not, currently it forces me to use mktemp, openssl, cat and rm, maybe I have to drop HTTPS, but I don't like to do so... will make up my mind about it.

The HTTP stuff I'm doing via the /dev/tcp-Fake-Dev that is available in Bash, doing request by an simple echo redirected to the fake dev and reading the response with cat. Currently I'm searching for something Bash-only to replace cat. For HTTPS I used the s_client command from openssl, but there the redirections does not work correctly, which requires me to use the commands from above paragraph. This not from my own thoughts, I've read up about it.

And now: Ducks: The code.

# Copyleft 2015 Christoph "criztovyl" Schulz
# GPL v3 and later
#!/usr/bin/env bash
fetch(){ 
    # Args: url
    local url=$1
    IFS=":" read -a parts<<<"$url"
    local proto=${parts[0]}
    type fetch_$proto &>/dev/null || echo "Protocol \"$proto\" not implemented." && fetch_$proto $url
}

http_https_host(){
    # Returns the host part of an url
    # Args: urlResource resultVar
    #  resultVar defaults to "host"
    local urlResource=$1
    local resultVar=$2
    [ -z "$resultVar" ] && resultVar="host"    

    IFS="/" read -a resource <<<"$urlResource"
    host="${resource[2]}"

    eval "$resultVar=$host"

}
fetch_http(){
    # Args: url urlParts
    local url=$1

    http_https_host $url
    echo "host $host"

    exec 3<> /dev/tcp/$host/80
    echo -e "GET $url HTTP/1.1\nHost: $host\nConnection: close\n\n" 1>&3
    cat 0<&3
}
fetch_https(){
    # Args: url urlParts
    local url=$1
    http_https_host $url
    echo "host $host"
    tmp=`mktemp`
    echo -e "GET $url\nHost: $host\nConnection: close\n\n" | openssl s_client -quiet -connect $host:443 2>/dev/null > $tmp
    cat $tmp
    rm -f $tmp
}
#fetch_ftp(){}
#fetch_from_dir(){}