Veni, Vidi, VISA

Ein Bekannter von mir hat Debian stretch laufen und wollte unbedingt die Powerline in Verbindung mit VIM 8.0 nutzen; installiert ist sie, da er sie bereits mit der Bash (*oergs*) und tmux (*yay*) verwendet. Nur mit VIM will sie nicht und das obwohl er sich an /usr/share/doc/powerline/README.Debian gehalten hat, in der folgendes steht:

your ~/.vimrc file:



  python from powerline.vim import setup as powerline_setup

  python powerline_setup()

  python del powerline_setup



Replace 'python' with 'python3' if appropriate.



Alternatively, if the vim-addon-manager package is installed, the following

command may be used:



  vim-addons install powerline

Und das obwohl Python ebenfalls installiert ist; sogar 2.7.13 und 3.5. Ist VIM aber egal und meldet sich noch immer mit

You need vim compiled with Python 2.6, 2.7 or 3.2 and later support

for Powerline to work. Please consult the documentation for more

details.

Press ENTER or type command to continue

zu Wort. Der Fehlerteufel lag im Detail; VIM 8.0 wurde via apt install vim installiert und da sieht es wie folgt aus:

$ vim --version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 23 2017 12:10:29)

[...]

Huge version without GUI.  Features included (+) or not (-):

[...]

+cryptv          +linebreak       -python          +vreplace

+cscope          +lispindent      -python3         +wildignore

[...]

und da die Powerline auf Python basiert, aber VIM keinen Interpreter dazu anbietet, funktioniert es nicht. Die Lösung war also apt install vim-nox oder VIM aus den Sourcen bauen und dem configure-Script ein --enable-pythoninterp=yes übergeben (oder halt python3interp).

Ist ein ganz netter Zeitvertreib: https://cmdchallenge.com

In meiner ~/.zsh/zshexports findet man u. a. den Abschnitt wo ich LS_COLORS setze, aber das geht auch anders bzw. einfacher. Unter https://github.com/trapd00r/LS_COLORS gibt es eine sehr erweiterte und ausführlich dokumentierte Version von LS_COLORS, welche mit eval $( dircolors -b $HOME/LS_COLORS ) gesetzt werden.

Wenn ein rm !(*.o|*.bak) mit einem event not found quittiert wird, dann ist die nicht kaputt, sondern will nur ein shopt -s extglob haben *meinjanur*

Kaum empfehle ich mal Debian, schon taucht ein Exploit dafuer auf. Und was fuer ein gefaehrliches. Man muss nur jemandem der in der Gruppe utmp ist dazu bringen chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp und schon funktioniert es. Gefaehrlich das.. zumal per Default root der einzige User ist der die Gruppe fuer /tmp/fillutmp auf utmp aendern koennte.

Wem faellt an folgenden beiden Dateien irgendwas besonderes auf:

$ head -n 10 /etc/passwd

root:x:0:0:root:/root:/bin/bash

bin:x:1:1:bin:/bin:/usr/bin/false

daemon:x:2:2:daemon:/sbin:/bin/false

adm:x:3:4:adm:/var/adm:/bin/false

lp:x:4:7:lp:/var/spool/lpd:/bin/false

sync:x:5:0:sync:/sbin:/bin/sync

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown

halt:x:7:0:halt:/sbin:/sbin/halt

mail:x:8:12:mail:/var/spool/mail:/bin/false

news:x:9:13:news:/usr/lib/news:/bin/false



$ sudo head -n 10 /etc/shadow

root:$1$xteAsH2S$jE1MfpCWfASZqMDiyH05J.:13569:0:::::

halt:*:9797:0:::::

operator:*:9797:0:::::

shutdown:*:9797:0:::::

sync:*:9797:0:::::

pseibold:$1$bgimUxzP$jG3Yna5v5MXJq7xPxuQ7s0:13569:0:99999:7:::

arichter:$1$beabnFio$g1gN7DCq.QlMWRHi2M2wh.:13801:0:99999:7:::

bin:$1$beabnFio$g1gN7DCq.IEKWRHeMADwh.:13424:0:::::

mathomas:$1$9Y.FexOi$PZxHAeCkWxA6gCkO9qOAT/:13638:0:99999:7:::

tleichner:$1$UXKd3nm8$4bh8WZ5eYVROpkAfu8y1O0:13801:0:99999:7:::

Die Loesung steht im erweitertem Beitrag "Preisfrage zur shadow/passwd" vollständig lesen

Sowas bekomme ich in letzter Zeit desoefteren zu hoeren, aber das ist nicht zwingend korrekt. Fakt ist, dass /bin/sh auf jedem Unix eine zu IEEE Std 1003.1 konforme Shell ist. Ein Shellscript das #!/bin/sh als Interpreter hat, wird auf jedem Unix (AIX, *BSD, SunOS, Linux, ..) korrekt gestartet und jetzt unterscheiden sich die Geister.
Zuerst kommt es darauf an wie man "Plattformunabhaengig" definiert. So wie Wikipedia es tut oder so, dass es ohne Aenderungen auf jedem System ohne Anpassungen funktioniert?! Es gibt u. a. im Usenet einige Luegner, die behaupten das es Unices ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. Ein Unix ohne /bin/sh ist kaputt! Ganz einfach. Bei den meisten Linuxdistributionen ist es ein "Quasistandard", dass /bin/sh ein Symlink auf die GNU Bash ist, aber das wars dann auch schon wieder. Unter *BSD ist /bin/sh eine PD-KSH wie man hier sehen kann

# uname -rs

OpenBSD 4.2

# strings /bin/sh | grep KSH

KSH_VERSION

@(#)PD KSH v5.2.14 99/07/13.2

Es spricht auch nichts dagegen wenn man Shellscripte schreibt, die eine bestimmte Shell voraussetzen, allerdings sollte man sich ueberlegen ob es zwingend notwendig ist das Script so zu schreiben.

// edit
Oben habe ich geschrieben das ein Unix ohne /bin/sh kaputt ist und das ist auch korrekt. Einige Luegner (u. a. im Usenet) behaupten zwar nach wie vor das es Systeme ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. /bin/sh zeigt immer auf eine zu POSIX konforme Shell. Wenn das nicht der Fall ist, wurde das manuell geaendert.
Ich lasse mich aber gerne ueberzeugen und mir ein Unix nennen, dass ohne /bin/sh laeuft.

• Die Zsh ist nicht kompatibel zur Bourne Shell,
• die Zsh ist nicht Bestandteil des GNU-Projektes,
• die Bash ist kleiner/schneller als die Zsh,
• die Zsh ist auf den meisten Systemen nicht vorhanden,
• die Bash hat UTF-8 - Unterstuetzung,
• die Zsh ist komplizierter als die Bash und fuer Anfaenger deswegen nicht brauchbar,
• Die Zsh versteht meinen PS1 nicht

"Wieso man die Z-Shell nicht verwenden will." vollständig lesen

Hier hab ich kurz beschrieben wie man bei einem exit-Status != 0 ein fortune-Cookie ausgeben laesst. Die Funktion TRAPZERR() steht aber nur bei der Zsh zur Verfuegung. Wenn man das gleiche mit der Bash haben will, muss man ERR trap(1)'en.

bash-3.00$ fnord



bash: fnord: command not found



bash-3.00$ trap "echo $(fortune bofh-excuses | tail -n 1)" ERR



bash-3.00$ fnord



bash: fnord: command not found



Im sorry a pentium wont do, you need an SGI to connect with us.



bash-3.00$

Die Bash beherrscht ja nichtmal Glob Qualifiers! Wenn ich nur die leeren Verzeichnisse ausgeben lassen will, muss ich Konstrukte wie

$ find . -empty -maxdepth 1 -type d

schreiben; bei der Zsh reicht ein

$ ls -ld *(/^F)

aber was richtig lustig ist, sind Sachen wie

$ find . \( -name . -o -prune \) \! -name '*.gz' \! -name '.*.gz' \! -name .gz -exec rm -rf {} \;

nur damit ich alle nicht *.gz - Dateien entfernen kann.

Bei der Zsh reicht ein

$ ls -ld -- ^*.gz

und was ebenfalls noch interessant wird, ist das case insensitive Abarbeiten von Strings und Variablen.

$ ls (#i)readme

listet alle Dateien mit dem Namen readme auf; gleichgueltig wie die Schreibweise ist und wenn man - wie ich - sich nie merken kann welches Ergebniss $OSTYPE enthaelt, dann kann man das mit

if [[ $OSTYPE == (#i)LinUX-gNu(#I) ]]; then



        echo "Penguin on board."



else



        echo "Not a Linux."



fi

abfragen.


Chris

$ autoload colors ; colors



$ print "$bg[red]$fg[black]Zu geil fuer diese Welt" >> /dev/pts/{1..9}

tian