[Erledigt] Freetz: Wildcards im Script funktionieren nicht

[PeterPawn]

Es war mir niemahls um die regexp zu tun.

Ok, das muß man aber erst mal verstehen, nachdem Du ja den "Sprung" von dem Ausdruck in #8, der auch "29:99" erlaubt hätte, auf eine bessere Alternative in #17 gemacht hast. Da muß man erst mal auf die Idee kommen, daß Du hier nur die Hälfte des Weges gehen wolltest - zumal sich #8 und #17 außer im regulären Ausdruck ja nur noch in den Quotes um $1 herum unterscheiden.

Ich bleibe trotzdem dabei, daß die Form mit "expr" noch andere Vorteile hat ggü. dem "echo" mit Pipe zum "egrep" ... erstens ist es ein Kommando weniger (einfach mal 10.000 Aufrufe messen, dann siehst Du den Unterschied) und zweitens ist bei meiner Version (dank des Vergleichs mit dem Ausgangswert) eigentlich sogar der "anchor" am Beginn (^) und am Ende ($) überflüssig (das ist quasi ein "doppeltes Netz"), weil irgendwelche Zeichen rundherum ja den Vergleich mit "$1" wieder scheitern lassen.

Das kann man also durchaus noch weiter vereinfachen ... aber nur dann, wenn es um den konkreten Einsatzfall hier geht. Wenn man das als "allgemeines Beispiel" verstanden wissen will, ist eine Vorsichtsmaßnahme mehr deutlich besser, als eine zuwenig.

Du warst es aber auch (und da ging es ja offensichtlich die Frage, ob man besser ein paar Klammern und Zeichen mehr verwenden sollte oder nicht), der das hier geschrieben hatte:

Schön das man mit Bash inline schöne Sachen machen kann, aber es sieht schnell ganz kryptisch aus und auch die viele Klammern machen es auch nicht schöner.

und da Dein Code in #8 noch einmal die ganzen Fehler und Probleme enthielt, auf die ich in #6 schon hingewiesen hatte, war es (zumindest für mich) nicht wirklich zu verstehen bzw. zu erkennen, daß Du damit nur Deine Vorliebe für "echo something | grep -q anything" mit anschließender Auswertung des Exit-Codes zum Ausdruck bringen wolltest und der Rest der Zeile Dich gar nicht weiter interessieren sollte.

Mal ganz abgesehen davon, daß ich extra noch dazugeschrieben hatte, daß die (vom mir im Beispiel angestrebte) POSIX-Kompatibilität als kleinster gemeinsamer Nenner das noch "komplizierter" aussehen läßt ... denn wer so etwas tatsächlich direkt für die "bash" und "inline" (was immer das sein mag) erstellt, der kann auch gleich auf "[[" und den "=~"-Operator zurückgreifen, wo einem dann auch noch der Wert in Stunden und Minuten aufgesplittet und als Variable bereitgestellt wird, wenn man den richtigen Ausdruck verwendet (mit "capture groups").

Formuliert man den regulären Ausdruck jedenfalls so, daß er wirklich narrensicher ist, sieht das am Ende (wie gesagt, ich hatte noch eine doppelte Absicherung drin und man kann sich auch für eine Version von den beiden folgenden entscheiden) in etwa so aus, wie hier:

[ "$(expr \( "$1" : '\(\([0-1 ]\?[0-9]\|2[0-3]\):[0-5]\?[0-9]\)' \) )" = "$1" ]
oder auch
[ "$(expr \( "$1" : '^\(\([0-1 ]\?[0-9]\|2[0-3]\):[0-5]\?[0-9]\)$' \) )" ]

(natürlich noch mit den Kommandos im "then"- und "else-Zweig") und damit reduziert sich die ganze Diskussion, wenn man gar nicht mehr auf den regulären Ausdruck schauen möchte (inhaltlich ist der nämlich identisch mit dem für "grep" oder "egrep", wenn er alles richtig abdecken soll), auf die Frage, ob eine Pipe

echo | (e)grep -q

oder ein einzelndes Kommando

expr

nun besser ist.

Die einen sagen so, die anderen so ... entscheidend ist und bleibt, daß es (a) funktioniert und (b) sicher ist und zwar (wenn es nicht anders erklärt wurde im Text) bei jedem Beispiel, was man anderen so zeigt - außer es steht noch daneben, worauf man sich "konzentriert" hat bei so einem Beispiel - man muß natürlich nicht bei jedem Beispiel immer alles bis ins letzte Detail auswalzen.

Aber wenn das später jemand "ohne Ahnung" (bzw. ohne den Kontext zu kennen) abtippt und bei einem >> echo $1 << nicht weiß, daß Du da bei Dir jedesmal noch Quotes außen herum setzt (also eigentlich >> echo "$1" << gemeint war), dann macht der das am Ende bei sich auch wieder falsch - ggf. mit "katastrophalen Folgen".

Auch die Frage, ob man nun die "simple Syntax" eines "grep" besser findet oder die "extended syntax" beim "egrep", ist meisten eher akademisch ... während die "extended syntax" mit mehr deutlich mehr Optionen einiges mit hoher Komplexität vielleicht etwas leichter macht ("Suche das dritte, durch "white spaces" getrennte, Wort in einer Zeile!"), bewirkt das manchmal auch glatt das Gegenteil, weil (als Beipiel) "[[:digit:]]" und "[0-9]" und auch "\d" am Ende fast dasselbe sind und trotzdem wohl die simple Syntax bei der mittleren Variante (die bei "simple" auch als einzige verstanden wird) die am leichtesten les- und schreibbare wäre.

Was aber zweifellos falsch war ... mein Verweis in #16 auf den Test mit "--" als Parameter beim "echo" klappt so tatsächlich nicht, weil (a) das "echo" als Builtin von der "bash" verwendet wird, solange man es nicht explizit als "/usr/bin/echo" aufruft und als Builtin kennt es nicht mal ein "--help" als Option und (b) ausgerechnet das "echo" dann die "double-dashes" für das Ende der Optionen beim Aufruf trotzdem nicht kennt bzw. es kontextbezogen interpretiert.

Aber am Beispiel in #19 (erster CODE-Block) siehst Du dann, worauf ich eigentlich hinauswollte, wenn ich von "unerwarteten Ergebnissen" schrieb, sofern man keine Quotes setzt.

Aber gerade bei Shell-Programmierung gibt es immer mehrere Wege (i.d.R. noch mehr, als in irgendeiner Programmiersprache, weil man mit unterschiedlichen Kommandos zu demselben Ziel gelangen kann) - das habe ich oben schon betont und so mag ja jeder seine eigenen Vorlieben haben und diese meinetwegen auch pflegen und "mehren" durch Empfehlungen für andere ... um so schöner, wenn er solche Empfehlungen dann auch noch begründen und "verteidigen" kann, indem er Vor- und Nachteile gegenüberstellt bei einem passenden Beispiel.