Weil man dann wieder ein Programm mehr braucht. Ein "cp" ist nunmal intuitiver zu erfassen als rcs oder cvs. Wenn schon, dann checkt man das komplette /etc in rcs ein. Aber für eine einzelne Datei rcs womöglich noch zu installieren ist gnadenloser overhead!
Wenn du nicht grad auf einem eingebetteten System bist ist der overhead so gnadenlos wohl nicht; RCS ist auf jedenfall eine saubere Lösung die viele Vorteile zu bieten hat..
Du installierst rcs, um mal gerade eben eine Datei zu ändern und dabei sicherstellen zu wollen, dass Du eine funktionierende Kopie behälst? Für mich ist das nicht nur gnadenloser overhead, sondern schierer Wahnsinn.
Für eine einzelne Datei mag es Overkill sein, aber wenn man ein größeres System wartet, kann das durchaus zum Rettungsanker werden, besonders wenn mehrere Leute damit beschäftigt sind. So lässt sich dann jederzeit schnell nachvollziehen, was wann geändert wurde. Ein vernünftiges Backup ersetzt das natürlich nicht.
entspricht auch garnicht der oben gestellten anforderung einfach nur ein backup einer datei mit datum zu erstellen ;o) man könnte es natürlich mit kommentaren versehen und mit unterschrift verifiziert in die schweizer berge schicken aber dann dauerts bis ich die datei ändern kann :o)
Hmm, ich mache, wenn ich weiss, mein Kollege fummelt auch an den /etc-Dateien rum, immer eine Kommentarzeile rein wie z.B.: # XY änderte am 12.03.2004 wegen blablabla folgende Zeile von: # alte Zeile # in: neue Zeile
und da ich ein "ordentlicher" Mensch bin wird jede Änderung, auch wenn ich allein im System bin, dokumentiert, schließlich will ich ja auch noch in 3 Jahren wissen, was die Zeile bedeutet, falls am Server nach 3 Jahren etwas nicht funktioniert.
Das mit den Dateirechten lässt sich mit getfacl und setfacl vielleicht lösen. Hab ein kleines (äusserst schlechtes da von mir, ungetetestes, vermutl. instabiles und unsicheres) script geschrieben, das das ganze automatisiert: http://www.linuxwiki.de/RCS_2fKonfigurationsVerwaltung
Sowas habe ich seit Ewigkeiten in der zentralen Profildatei drin, allerdings ohne den Test und mit Punkt und Datum in Klammern statt dem Unterstrich. War mal in einem alten Unix-Handbuch aufgeführt und hat sich bei mir schon oft bewährt und mir viel Ärger erspart.
Von conter_anonymous am Fr, 12. März 2004 um 08:21 #
Warum sollte das nicht funktionieren? Entweder Du benutzt die bashexpansion für den Dateinamen oder Du maskierst selbst die Leerzeichen oder gleich den ganzen Dateinamen.
was bringt mir "test -e" ? Das halte ich nur für notwendig, vertippe ich mich mal (bei tabcomplete eh schwer möglich) Ich mag trotzdem Dateien mit Leerzeichen wegsichern...
> wer editiert schon Window$ Dateien
Nunja, war ein Beispiel. Gibt ja Mediendateien mit allen möglichen Sonderzeichen. Die kann ich sonst auch ansprechen, also solls im Script auch möglich sein.
Zugegeben, ein bisschen verbesserungswürdig ist die Funktion schon, aber das ändert nix am Prinzip. Meine Version:
function backup { for FILE ; do [[ -e "$FILE" }]] && cp "$FILE" "${FILE}_$(date +%Y%m%d)" || echo "\"$FILE\" not found." >&2 done }
Ist "Datei mit Leerzeichen"-sicher, kann mehrere Dateien auf einmal kopieren, verwendet eine 4stellige Jahreszahl und schreibt Fehlermeldungen nach stderr. Nachteil ist ggf. die bash/ksh-Syntax; in sh ginge es aber auch, wenn auch mit einem kleinen Umweg.
Schade, dass hier pre- oder code-Tags nicht funktionieren...
Dein Beispiel ist leider voellig unbrauchbar, da noch nicht einmal die Syntax korrekt ist. Vielleicht das naechste mal vorm posten testen. Schliesslich lesen hier auch Leute mit die keine Ahnung vom Shell-Skripten haben.
Nun, warum postest Du dann nicht direkt die Korrektur? Manchmal macht man halt auch mal Fehler... Also, die schliessende geschweifte Klammer innerhalb der [[ ]] hat dort nichts zu suchen. Korrektur:
function backup { for FILE ; do [[ -e "$FILE" ]] && cp "$FILE" "${FILE}_$(date +%Y%m%d)" || echo "\"$FILE\" not found." >&2 done }
Ich würde die Funktion aber (der Übersichtlichkeit) eher so schreiben und außerdem %s stat "%y%m%m" benutzen:
backup() { if [ -e "$1" ]; then cp "$1" "$1_$(date +%s)" else echo "$1: No such file or directory". fi }
Es ist zwar etwas länger, aber man hat imho so ein strukturierteres Programm. Auch sind `` "deprecated" soweit ich weiss. Das letzte: %s hängt die aktuelle Zahl von Sekunden seit 1970 an die Datei an und garantiert so einen vorlaufenden Timer, denn das derzeitige backup-Programm checkt nicht ob im selben Tag schon eine Datei editiert wurde.
Grundsätzlich ganz gut. Aber die Fehlerausgabe auf STDOUT macht keinen Sinn, ausserdem wird im Fehlerfall (Datei existiert nicht) kein entsprechender exit-Code (1) sondern 0 ausgegeben (Da das echo 0 liefert)
Der urspruengliche Vorschlag war wirkich undurchdacht. Warum sollte man eine einzelne Fehlerursache herauspicken und anders behandeln als alle anderen Fehler die auftreten koennen? Und warum sollte man den dann auch noch falsch behandeln, ohne Fehlercode usw.? Zu bedenken ist hier auch noch die Usability. Jede von cp (bzw. Standard-Tools) generierte Fehlermeldung ist internationalisiert, jede hart ins Skript gecodete nicht.
Aber auch hier werden noch Fehler falsch behandelt. Einen leeren Dateinamen wird cp auch bemaengeln (die Datei wird nicht existieren, fertig). Eigentliche Intention duerfte hier gewesen sein, den Fall abzufangen, dass backup ohne Argument aufgerufen wird. Dafuer ist dann aber der Test falsch.
Ah, danke für die Auskunft. Das ist ja nun das Basispaket mit den wichtigsten Verzeichnissen und so... Da werde ich mal auf der SLES8 nachsehen müssen.
Hallo Leute, obwohl schon so manches Linux-System installiert, betrachte ich mich noch als "Linux-Neuling". Ich bin aber beruflich bedingt nicht in der Lage, mich voll auf Linux zu konzentrieren. Deshalb sind mir alle Tipps und Hilfen willkommen. Ja, ich bin ein "Windows-geschaedigter", und ja, ich bin "GUI-verwoehnt". Aber ich moechte lernen.
Wenn ich mir nun diesen Artikel anschaue (den ich wie meistens bei pro-linux sehr schaetze), und dann die sich anschliessende Diskussion, frage ich mich, ob sich hier einfach nur ein paar Experten oder Gurus in ihrer "Fachsprache" unterhalten wollen (im doppelten Wortsinn), oder ob dies auch einen echten Nutzen fuer Neulinge und Einsteiger bringen soll. Vielleicht sind aber auch manche mit dem Nischendasein von Linux zufrieden? (Falls das zutreffend ist). ich glaube aber und hoffe, dass sich Linux auch auf dem Desktop durchsetzen muss.
pro-linux schreibt in seiner Erklaerung u.a.: "Wir wollen insbesondere Linux-Neulingen bei den ersten Schritten mit Linux helfen, aber auch für die Fortgeschrittenen und Profis interessante Themen bieten."
Zurueck zum vorliegenden Artikel und der Diskussion. Mein Argument ist folgendes: Dieser Artikel zielt doch eigentlich auf Neulinge. Experten wissen das doch laengst oder wissen sich entsprechend zu helfen. Ein solcher Tipp ist aber langfristig nur hilfreich, wenn er auch genau erklaert, wie das Script in diesem Fall funktioniert - sonst uebernimmt man es einfach ohne zu verstehen, warum. Statt hier also drueber zu streiten, ob nun RCS, CSV oder XYZ besser gewesen waere, und das in einer Sprache, die Neulinge nicht verstehen, sollte man lieber versuchen, diesen Script und die Idee dahinter fuer Einsteiger transparenter zu machen.
Natuerlich koennte ich hergehen, und jetzt muehsam aus dem Handbuch mir das Script "uebersetzen". Aber effektiver waere doch, die Sprache anhand praktischer Alltagsbeispiele wie diesem erklaert zu bekommen.
Nichts fuer ungut, trotzdem moechte ich mich bei dieser Gelegenheit fuer das allgemeine Engagement hier bedanken. :)
Ja, es macht Sinn so eine Zeile einmal seziert zu bekommen, weil sonst weiss man nicht einmal wo ein Befehl aufhoert und der naechste anfaengt. Die man-Pages sind nicht fuer Anfaenger geeignet, habe ich selber probiert und es fehlen solche "Sezierarbeiten" wie oben. Danke, solche Hilfe ist wirklich brauchbar!
Wieder was gelernt. So langsam fange ich an, Linux auch zu mögen und nicht nur zu benutzen, weil es notwendig ist. Und um ehrlich zu sein habe ich schon eine ganze Weile sowas gesucht, denn bisher machte ich das immer per Hand.
Vielen Dank für den wertvollen Kommentar (einer der meist leider wenigen hier)! :-) Mach ich also gleich weiter:
RCSund CVSsind Verwaltungssysteme, die mit Hilfe von Versionen Dateien im Zusammenhang (gleicher Version) speichern. Jede neue Version einer Datei wird in das zentrale System (oft ein anderer Server) "eingecheckt". Es gibt also einen CVS-Server und CVS-Clients. CVS-Clients gibt es als Kommandozeile und natürlich auch mit graf. Oberfläche und zwar für alle Betriebssysteme, d.h. man kann Daten so auch sehr gut zwischen Systemen austauschen. Mehr zu CVS findet man z.B. unter http://www.suse.de/de/private/support/online_help/howto/cvs/cvs.html (auf deutsch) ;-) Jede alte Version kann dann zu einer beliebigen Version (einem best. Zeitpunt z. B.) zurückgesetzt werden. Ein CVS kann für sehr viele Sachen sehr gewinnbringend eingesetzt werden und sollte auf keiner Workstation fehlen:
Konfigurationsdateien können schnell und übersichtlich gesichert werden.
Programmierer können ihren Programmcode im Team verwalten und austauschen
Es können sehr schnell Replikate hochgezogen werden (Unser Admin macht das z.B. für DNS!)
Man kann es als Datenpool oder auch Wissenspool verwenden (in kl. und mittl. Firmen oft schwer vermisst)
etc. (wer schreibt noch was??
Noch ein Wort zur Einrichtung: Der Server kann in den meisten Distris einfach als Paket installiert werden; der Start sollte automatisch über den init-Prozess erfolgen. Der Rest kann zu 99% einfach über einen graf. Client erfolgen, also das Einrichten von Projekten, das Ein- und Auschecken, etc.
backup() # Funktionsdefinition { DATEINAME="$1" # DATEINAME auf das erste Argument der Funktion setzen if [ -e "$DATEINAME" ] # Wenn die Datei existiert ...
# [ ist ein Alias auf das Programm test, siehe auch "man test"
then # dann
cp "$1" "${DATEINAME}_$(date +%s)" # kopiere das ganze zum Backup mit dem Datum angehängt
# Die geschweiften Klammern müssen sein, da sonst der Unterstrich zu $DATEINAME gehörig betrachtet würde.
else # ansonsten (also wenn die if-Bedingung nicht zutrifft; der Test fehlschlägt)
echo "$DATEINAME: No such file or directory." 1>&2 # Gib eine Fehlermeldung auf der Standardfehlerausgabe aus
# 1>&2 leitet alles von der Standardausgabe (kurz: stdout) zur Standardfehlerausgabe (kurz: stderr)
return 1 # Gib einen Fehlercode von 1 zurück.
fi
return 0 # Alles ok, der Fehlercode $? ist dann gleich 0
}
Hoffe das hilft ein wenig. (# ist immer ein Kommentar)
date +%Y-%m-%d gibt 2004-03-12? Was soll das sein? 12.März 2004 oder doch der 3.Dezember? Du schießt Dir gerade ins Knie. Denn wer kann sich in 10 Jahren noch an den ISO-Standard erinnern? Dann schon lieber `date -R`
Und überhaupt: Sollte man nicht zuerst einmal überprüfen, ob man nicht eine Datei überschreibt? Vielleicht existiert /etc/passwd_Sat_13 Mar_2004_01:52:54_+0100 ja schon?
Außerdem will man in 10 Jahren vielleicht wissen, wer das gemacht hat: `whoami` Zeitzone wäre nicht auch schlecht: `cat /etc/timezone` Auf welchem Rechner eigentlich? `uname -a` Vorsichtshalber mal mit ROT-13 verschlüsseln? `tr a-z n-za-m` Oder lieber sicherheitshalber alles dranhängen? Sicher ist sicher! `find / -type f -exec cat {} \;`
date +%Y-%m-%d gibt 2004-03-12? Was soll das sein? 12.März 2004 oder doch der 3.Dezember? Du schießt Dir gerade ins Knie. Denn wer kann sich in 10 Jahren noch an den ISO-Standard erinnern? Dann schon lieber `date -R`
Leute, die nicht die geringste Ahnung von der Bedeutung der Standardisierung für die Ingenieurwissenschaften haben, also auch kein ISO-Datumsformat korrekt interpretieren können, haben ohnehin auf einem System nichts zu administrieren. Bei solchen Einstellungen, wie der obig zitierten, braucht man sich nicht zu wundern, warum die IT immer noch Lichtjahre vom Qualitätsstandard richtiger Ingenieurwissenschaften entfernt ist.
Du meinst beispielsweise den Qualitätsstandard der NASA-Ingenieure, die sich nicht einigen können, ob sie im amerikanischen oder im metrischen System rechnen sollen?
Da ist die Informatik *hoffentlich* noch Lichtjahre von deren Qualitätsstandard entfernt.
in dem Kurztip ging es darum, eine Funktion zu automatisieren, die ein Backup einer Konfigurationsdatei anlegt, um eine funktionierende Version dieser Datei bei Bedarf wieder einspielen zu können.
Wenn man sauber arbeitet, werden solche Backup-Dateien gelöscht, sobald man merkt, dass die geänderte Konfigurationsdatei funktioniert. Es ist also scheissegal, wie man diese Backupdatei nennt. Ob nun *.bak, *.orig, *.sicherung, *.xyz oder *.2004_03_13 spielt keine Rolle, da diese Datei (hoffentlich) nicht länger als 5 Minuten existiert. Wer da mit igendwelchen ISO-Standards ankommt hat eindeutig einen Sprung in der Schüssel.
Es ist doch ganz einfach, YYYY-MM-TT ist immer der zeitlichen Reihenfolge nach sortiert. Wer MM und TT vertauscht, der sollte lieber wieder im Sandkasten spielen.
Ja mache ich auch so bei Logfiles. Gibt es auch einen ISO Standard, der Stunde und Minute hier anfuegt? JJJJ-MM-TT_ss-mm ? Oder wie wird das unter ISO gehandhabt?
# Verzeichnis Monat-Jahr machen damit alte Sicherheitskopien leichter # weggelöscht werden können DateiGroesse=`wc -c < $1` if [ $DateiGroesse -le 9999999 -a $DateiGroesse -ne 0 ] then mkdir -p /home/backup/$MonatJahr cp $1 /home/backup/$MonatJahr/$NurName && echo "Kopieren erfolgreich" #---> test -e /q/backup/$MonatJahr/$NurName && echo "Datei wurde angelegt" else echo "----- Datei >= 10MB oder = 0 --- KEINE SICHERHEITSKOPIE ----" fi
| $ mkdir RCS
| $ ci -l ...
viel uebersichtlicher, und Aenderungen sind dokumentierbar
Ein vernünftiges Backup ersetzt das natürlich nicht.
man könnte es natürlich mit kommentaren versehen und mit unterschrift verifiziert in die schweizer berge schicken aber dann dauerts bis ich die datei ändern kann :o)
# XY änderte am 12.03.2004 wegen blablabla folgende Zeile von:
# alte Zeile
# in:
neue Zeile
und da ich ein "ordentlicher" Mensch bin wird jede Änderung, auch wenn ich allein im System bin, dokumentiert, schließlich will ich ja auch noch in 3 Jahren wissen, was die Zeile bedeutet, falls am Server nach 3 Jahren etwas nicht funktioniert.
olli
http://www.linuxwiki.de/RCS/KonfigurationsVerwaltung
Leider haben diese bash-Tipps ein Problem das niemand beachtet: sobald ich eine Datei mit Leerzeichen hab ist es vorbei!
mit "test.sh" funktioniert es wunderbar: "test.sh_040312"
mit "t e 2 ! . s_ H0 1" funktioniert es nicht: no such file...
Zugegeben, war sogar aus meiner Sicht ein extremes Beispiel ;-)
Aber solche Dateien sollen vorkommen *ans.Windows.tock.tock.tock...*
auserdem, wer editiert schon Window$ Dateien?? :o)
Ich mag trotzdem Dateien mit Leerzeichen wegsichern...
> wer editiert schon Window$ Dateien
Nunja, war ein Beispiel. Gibt ja Mediendateien mit allen möglichen Sonderzeichen. Die kann ich sonst auch ansprechen, also solls im Script auch möglich sein.
function backup {
for FILE ; do
[[ -e "$FILE" }]] && cp "$FILE" "${FILE}_$(date +%Y%m%d)" || echo "\"$FILE\" not found." >&2
done
}
Ist "Datei mit Leerzeichen"-sicher, kann mehrere Dateien auf einmal kopieren, verwendet eine 4stellige Jahreszahl und schreibt Fehlermeldungen nach stderr. Nachteil ist ggf. die bash/ksh-Syntax; in sh ginge es aber auch, wenn auch mit einem kleinen Umweg.
Schade, dass hier pre- oder code-Tags nicht funktionieren...
Jochen
Vielleicht das naechste mal vorm posten testen. Schliesslich lesen hier auch Leute mit die
keine Ahnung vom Shell-Skripten haben.
Nun, warum postest Du dann nicht direkt die Korrektur? Manchmal macht man halt auch mal Fehler... Also, die schliessende geschweifte Klammer innerhalb der [[ ]] hat dort nichts zu suchen. Korrektur:
function backup {
for FILE ; do
[[ -e "$FILE" ]] && cp "$FILE" "${FILE}_$(date +%Y%m%d)" || echo "\"$FILE\" not found." >&2
done
}
Jochen
backup()
{
if [ -e "$1" ]; then
cp "$1" "$1_$(date +%s)"
else
echo "$1: No such file or directory".
fi
}
Es ist zwar etwas länger, aber man hat imho so ein strukturierteres Programm. Auch sind `` "deprecated" soweit ich weiss. Das letzte: %s hängt die aktuelle Zahl von Sekunden seit 1970 an die Datei an und garantiert so einen vorlaufenden Timer, denn das derzeitige backup-Programm checkt nicht ob im selben Tag schon eine Datei editiert wurde.
Für größere Systeme bin ich auch für CVS :-)
cu
Fabian
Besser cp das error-handling machen lassen:
backup()
{
[ -n "$1" ] && cp "$1" "$1_$(date +%s)"
}
Grüße, Jürgen
Jochen
-n ist da schon richtig, da hier ja cp das Fehler-Handling übernimmt ...
cu
Fabian
Der urspruengliche Vorschlag war wirkich undurchdacht. Warum sollte man eine
einzelne Fehlerursache herauspicken und anders behandeln als alle anderen Fehler die auftreten
koennen? Und warum sollte man den dann auch noch falsch behandeln, ohne Fehlercode usw.?
Zu bedenken ist hier auch noch die Usability. Jede von cp (bzw. Standard-Tools) generierte
Fehlermeldung ist internationalisiert, jede hart ins Skript gecodete nicht.
Aber auch hier werden noch Fehler falsch behandelt. Einen leeren Dateinamen wird cp auch
bemaengeln (die Datei wird nicht existieren, fertig). Eigentliche Intention duerfte hier
gewesen sein, den Fall abzufangen, dass backup ohne Argument aufgerufen wird. Dafuer ist
dann aber der Test falsch.
Besser:
backup() {
test $# = 1 || { echo >&2 "usage: backup FILE"; return 1; }
cp "$1" "$1_`date ...`"
}
cat /usr/bin/old
...
Jochen
bei SuSE (zumindest 8.2 & 9.0) ist es Bestandteil des Pakets "aaa_base".
Gruß
Jochen
Wenn ich mir nun diesen Artikel anschaue (den ich wie meistens bei pro-linux sehr schaetze), und dann die sich anschliessende Diskussion, frage ich mich, ob sich hier einfach nur ein paar Experten oder Gurus in ihrer "Fachsprache" unterhalten wollen (im doppelten Wortsinn), oder ob dies auch einen echten Nutzen fuer Neulinge und Einsteiger bringen soll. Vielleicht sind aber auch manche mit dem Nischendasein von Linux zufrieden? (Falls das zutreffend ist). ich glaube aber und hoffe, dass sich Linux auch auf dem Desktop durchsetzen muss.
pro-linux schreibt in seiner Erklaerung u.a.: "Wir wollen insbesondere Linux-Neulingen bei den ersten Schritten mit Linux helfen, aber auch für die Fortgeschrittenen und Profis interessante Themen bieten."
Zurueck zum vorliegenden Artikel und der Diskussion. Mein Argument ist folgendes: Dieser Artikel zielt doch eigentlich auf Neulinge. Experten wissen das doch laengst oder wissen sich entsprechend zu helfen. Ein solcher Tipp ist aber langfristig nur hilfreich, wenn er auch genau erklaert, wie das Script in diesem Fall funktioniert - sonst uebernimmt man es einfach ohne zu verstehen, warum. Statt hier also drueber zu streiten, ob nun RCS, CSV oder XYZ
besser gewesen waere, und das in einer Sprache, die Neulinge nicht verstehen, sollte man lieber versuchen, diesen Script und die Idee dahinter fuer Einsteiger transparenter zu machen.
Natuerlich koennte ich hergehen, und jetzt muehsam aus dem Handbuch mir das Script "uebersetzen". Aber effektiver waere doch, die Sprache anhand praktischer Alltagsbeispiele wie diesem erklaert zu bekommen.
Nichts fuer ungut, trotzdem moechte ich mich bei dieser Gelegenheit fuer das allgemeine Engagement hier bedanken.
:)
Greetings,
Matthy from Ireland
backup() {
Funktionsdefinition
test -e $1
Abfrage: Wenn Argument ($1 - in diesem Fall Dateiname) existiert dann:
cp $1 $1_`date +%y%m%d`
Kopiere (cp) Datei $1 als Dateiname ($1)+die Ausgabe von Datum (date +%y%m%d).
Im Falle, dass Datei $1 nicht existiert (||), gebe eine Fehlermeldung (echo) aus.
Du kannst auch die Ausgaben auch separat testen:
test -e "Dateiname" && echo "Datei vorhanden" || echo "Datei nicht vorhanden"
oder die Augabe der neuen Datei+Datum
echo "Dateiname"_`date +%y%m%d`
Wenn Du also stallt echo cp benutzt, wird die Datei umkopiert:
cp "Dateiname" "Dateiname"_`date +%y%m%d`
oder eben als Parameter in einer Funktion:
cp $1 $1_`date +%y%m%d`
Ob es allerdings wirklich Sinn macht, jede Zeile eines Scripts zu erklaeren, mag ich nicht kommentieren
Danke, solche Hilfe ist wirklich brauchbar!
liquidat
So langsam fange ich an, Linux auch zu mögen und nicht nur zu benutzen, weil es notwendig ist. Und um ehrlich zu sein habe ich schon eine ganze Weile sowas gesucht, denn bisher machte ich das immer per Hand.
Mach ich also gleich weiter:
RCSund CVSsind Verwaltungssysteme, die mit Hilfe von Versionen Dateien im Zusammenhang (gleicher Version) speichern.
Jede neue Version einer Datei wird in das zentrale System (oft ein anderer Server) "eingecheckt".
Es gibt also einen CVS-Server und CVS-Clients. CVS-Clients gibt es als Kommandozeile und natürlich auch mit graf. Oberfläche und zwar für alle Betriebssysteme, d.h. man kann Daten so auch sehr gut zwischen Systemen austauschen.
Mehr zu CVS findet man z.B. unter http://www.suse.de/de/private/support/online_help/howto/cvs/cvs.html (auf deutsch) ;-)
Jede alte Version kann dann zu einer beliebigen Version (einem best. Zeitpunt z. B.) zurückgesetzt werden.
Ein CVS kann für sehr viele Sachen sehr gewinnbringend eingesetzt werden und sollte auf keiner Workstation fehlen:
Noch ein Wort zur Einrichtung:
Der Server kann in den meisten Distris einfach als Paket installiert werden; der Start sollte automatisch über den init-Prozess erfolgen.
Der Rest kann zu 99% einfach über einen graf. Client erfolgen, also das Einrichten von Projekten, das Ein- und Auschecken, etc.
Cheers
backup() # Funktionsdefinition
{
DATEINAME="$1" # DATEINAME auf das erste Argument der Funktion setzen
if [ -e "$DATEINAME" ] # Wenn die Datei existiert ...
# [ ist ein Alias auf das Programm test, siehe auch "man test"
then # dann
cp "$1" "${DATEINAME}_$(date +%s)" # kopiere das ganze zum Backup mit dem Datum angehängt
# Die geschweiften Klammern müssen sein, da sonst der Unterstrich zu $DATEINAME gehörig betrachtet würde.
else # ansonsten (also wenn die if-Bedingung nicht zutrifft; der Test fehlschlägt)
echo "$DATEINAME: No such file or directory." 1>&2 # Gib eine Fehlermeldung auf der Standardfehlerausgabe aus
# 1>&2 leitet alles von der Standardausgabe (kurz: stdout) zur Standardfehlerausgabe (kurz: stderr)
return 1 # Gib einen Fehlercode von 1 zurück.
fi
return 0 # Alles ok, der Fehlercode $? ist dann gleich 0
}
Hoffe das hilft ein wenig. (# ist immer ein Kommentar)
cu
Fabian
Die linuxfibel (www.linuxfibel.de) hat einen ausführlichen Kurs und das bei Linuxwiki.de/Bash finden sich weitere nützliche Links.
cu
Fabian
JJJJ-MM-TT
So und nicht anders gehört es, da gibt's keine Mißverständnisse und keine Probleme und richtig sortiert wird es auch.
Oder was soll denn bitte 040602 sein?
2. Juni 2004?
4. Juni 2002?
6. April 2002?
Wäre alles möglich, in 10 Jahren weiß kein Mensch mehr was das für ein Datum ist.
Also bitte:
backup() {
test -e $1 && cp $1 $1_`date +%Y-%m-%d` ||
echo $1: No such file or directory;
}
Was soll das sein? 12.März 2004 oder doch der 3.Dezember?
Du schießt Dir gerade ins Knie. Denn wer kann sich in 10 Jahren noch an den ISO-Standard erinnern? Dann schon lieber `date -R`
Und überhaupt: Sollte man nicht zuerst einmal überprüfen, ob man nicht eine Datei überschreibt? Vielleicht existiert /etc/passwd_Sat_13 Mar_2004_01:52:54_+0100 ja schon?
Außerdem will man in 10 Jahren vielleicht wissen, wer das gemacht hat: `whoami`
Zeitzone wäre nicht auch schlecht: `cat /etc/timezone`
Auf welchem Rechner eigentlich? `uname -a`
Vorsichtshalber mal mit ROT-13 verschlüsseln? `tr a-z n-za-m`
Oder lieber sicherheitshalber alles dranhängen? Sicher ist sicher! `find / -type f -exec cat {} \;`
Was soll das sein? 12.März 2004 oder doch der 3.Dezember?
Du schießt Dir gerade ins Knie. Denn wer kann sich in 10 Jahren noch an den ISO-Standard erinnern? Dann schon lieber `date -R`
Leute, die nicht die geringste Ahnung von der Bedeutung der Standardisierung für die Ingenieurwissenschaften haben, also auch kein ISO-Datumsformat korrekt interpretieren können, haben ohnehin auf einem System nichts zu administrieren.
Bei solchen Einstellungen, wie der obig zitierten, braucht man sich nicht zu wundern, warum die IT immer noch Lichtjahre vom Qualitätsstandard richtiger Ingenieurwissenschaften entfernt ist.
Da ist die Informatik *hoffentlich* noch Lichtjahre von deren Qualitätsstandard entfernt.
in dem Kurztip ging es darum, eine Funktion zu automatisieren, die ein Backup einer Konfigurationsdatei anlegt, um eine funktionierende Version dieser Datei bei Bedarf wieder einspielen zu können.
Wenn man sauber arbeitet, werden solche Backup-Dateien gelöscht, sobald man merkt, dass die geänderte Konfigurationsdatei funktioniert. Es ist also scheissegal, wie man diese Backupdatei nennt. Ob nun *.bak, *.orig, *.sicherung, *.xyz oder *.2004_03_13 spielt keine Rolle, da diese Datei (hoffentlich) nicht länger als 5 Minuten existiert. Wer da mit igendwelchen ISO-Standards ankommt hat eindeutig einen Sprung in der Schüssel.
Außerdem ist genau das ja der Punkt, dass man ein eindeutiges STANDARDISIERTES Format verwendet.
$ date --iso-8601=seconds
2004-03-13T16:44:41+0100
Ecaroh < mail to : ecaroh bei arcor punkt de >
konsole=$(tty)
# Variablen vorbereiten
MonatJahr=`date +%Y-%m`
NeuerName=$1_`date +%Y-%m-%d--%H-%M-%S`
NurName=$(basename $NeuerName)
# Verzeichnis Monat-Jahr machen damit alte Sicherheitskopien leichter
# weggelöscht werden können
DateiGroesse=`wc -c < $1`
if [ $DateiGroesse -le 9999999 -a $DateiGroesse -ne 0 ]
then
mkdir -p /home/backup/$MonatJahr
cp $1 /home/backup/$MonatJahr/$NurName && echo "Kopieren erfolgreich"
#---> test -e /q/backup/$MonatJahr/$NurName && echo "Datei wurde angelegt"
else
echo "----- Datei >= 10MB oder = 0 --- KEINE SICHERHEITSKOPIE ----"
fi