GIT-Submodul version auslesen

[Assarbad]

Öhm, ich halte mich mal mit Kritik gediegen zurück. Scheinst ja noch feucht hinter den Ohren zu sein in Sachen Bash

Zitat von himitsu:

Bash kann einem aber schon ein bissl abschrecken und für alles gibt es tausende Wege, wo man die Vorschläge/Tutorials im Internet oft nur schwer versteht.
Und die Hilfe kann einen auch manchmal erschrecken, so dass man gleich wegrennen will.

Zitat:

Bash supports a surprising number of string manipulation operations. Unfortunately, these tools lack a unified focus. Some are a subset of parameter substitution, and others fall under the functionality of the UNIX expr command. This results in inconsistent command syntax and overlap of functionality, not to mention confusion.

aus https://www.tldp.org/LDP/abs/html/st...ipulation.html
Klingt schon ein bisschen nach: bash ist bissl davon und ein bissl davon, aber von nichts was richtiges.
Ich will jetzt aber kein bashing betreiben.

Es mag Inkonsistenzen bei Bash geben, aber einiges davon ist auch einfach der Tatsache geschuldet, daß es einige Dinge aus dem POSIX-Standard erbt, andere aber sinnvoll selbst implementiert. Bspw. würde ich immer empfehlen [[ ]] für Bedingungen in Bash zu benutzen, weil es einfach weniger Probleme macht in diversen Grenzfällen (bspw. wenn eine Variable zu einem leeren String expandiert usw.).

Im Gegensatz zu diversen Werkzeugen wie cut oder tr oder cat, soll eine Shell ja auch mehr können.

Außerdem hat Bash dann bspw. "let" für arithmetische Zuweisungen und $(()) sowie (())-Bedingungen. Da läßt sich auch einiges mit anstellen wenn auch leider nicht mit Gleitkommazahlen (die kann man wiederum mit expr verarbeiten).

$() sollte man den Backticks vorziehen, weil Backticks zum Alptraum werden, wenn man sie schachtelt. Bei $() ist dies kein Problem.

Alles in allem würde ich dir empfehlen dir das Bash Cookbook - welches frei als PDF verfügbar ist (und ja, legal!) - durchzuarbeiten.

Traditionell werden Variablen in Großbuchstaben gehalten um sie bspw. von Befehlen zu unterscheiden, aber ist Geschmackssache. Hat aber Vorteile sich an etablierte Konventionen zu halten.

Da hier:

Code:

#!/bin/bash

##### Input :: bash git-info.sh DIR DEST [|branch|version|log]
gitdir=$1
dest=$2
mode=$3
if [ -n "$gitdir" ]; then gitdir="$(cygpath -u "$gitdir")"; fi
if [ -n "$dest" ];   then dest="$(cygpath -u "$dest")"; fi

... wäre so besser:

Code:

#!/usr/bin/env bash

##### Input :: bash git-info.sh DIR DEST [|branch|version|log]
gitdir=$1
dest=$2
mode=$3
[[ -z "$gitdir" ]] || gitdir="$(cygpath -u "$gitdir")"
[[ -z "$dest" ]] || dest="$(cygpath -u "$dest")"

... oder halt für die letzten beiden Zeilen:

Code:

[[ -n "$gitdir" ]] && gitdir="$(cygpath -u "$gitdir")"
[[ -n "$dest" ]] && dest="$(cygpath -u "$dest")"

... und den drei Variablen könntest du jeweils auch Standardwerte zuordnen.

Kurzer Exkurs: die Hashbang oben ist die portabelste die du bekommen kannst. Funktioniert auf Linux, macOS, BSDs, AIX usw. gleichermaßen, weil env in all diesem Betriebssystemen am selben Ort liegt. Man kann sich also auf den Pfad zu env verlassen und mit dessen Hilfe den zu Bash ermitteln. Für Skripte die als Superuser laufen, würde ich dennoch den Pfad hartkodieren um möglichen Rechteausweitungen vorzugreifen.

Bspw. "log" für den dritten:

Code:

mode=${3:-log}

Und wenn du ein frisches Skript beginnst, bietet sich

Code:

set -e

... an. Damit werden alle ungeprüften Rückgabewerte die nicht 0 sind, zum Beenden des Skripts führen. Fördert manchmal die Disziplin.