Das passiert, weil das, was ich in Post #19 geschrieben habe, offensichtlich nur mit der BSD-Syntax (so heißt das, glaube ich) geht:
0 ✓ rne@zbox ~ $ mkdir tmp
0 ✓ rne@zbox ~ $ cd tmp/
0 ✓ rne@zbox ~/tmp $ ls
0 ✓ rne@zbox ~/tmp $ pwd
/home/rne/tmp
0 ✓ rne@zbox ~/tmp $ ls
0 ✓ rne@zbox ~/tmp $ tar -cvfz work.tar.gz --exclude="/var/cache/pacman/pkg/*" /var/cache/pacman
tar: work.tar.gz: Funktion stat fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
tar: Entferne führende „/“ von Elementnamen
/var/cache/pacman/
/var/cache/pacman/pkg/
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler
2 ✗ rne@zbox ~/tmp $ ls
z
0 ✓ rne@zbox ~/tmp $ rm z
0 ✓ rne@zbox ~/tmp $ tar cvfz work.tar.gz --exclude="/var/cache/pacman/pkg/*" /var/cache/pacman
tar: Entferne führende „/“ von Elementnamen
/var/cache/pacman/
/var/cache/pacman/pkg/
0 ✓ rne@zbox ~/tmp $ ls
work.tar.gz
Mit der POSIX Syntax wird die auf "f" folgende Zeichenkette bereits als Dateiname ("z") interpretiert und
work.tar.gz daher als
FILE und nicht
ARCHIVE.
Ich stelle im Verlauf dieses Threads, in dem ich ungewollt viel über die Argumentstruktur und das Verhalten von tar gelernt habe, dass dieses, auf die Parameter bezogen, eine unberechenbare Zicke ist.