BSD Style cp, rsync, dump, restore (…) durch GNU Style ersetzen

S

sevY

Hi,

hat jemand Erfahrungen damit, die unter Mac OS X verfügbaren Tools wie cp, rsync usw. durch die verbesserten GNU Exemplare zu ersetzen?

Ein Script wie folgendes ist z.B. zum Rotieren von Backups unter OS X nicht ohne weiteres ausführbar, da „cp“ die Parameter -a und -l nicht kennt…

Code: 
#!/bin/bash
#(…)
if [ -d $DATA_PATH/$SERVER/daily.0 ] ; then
        cp -al $DATA_PATH/$SERVER/daily.0 $DATA_PATH/$SERVER/daily.1
fi
#(…)



Bei „dump“ vermisse ich ebenfalls einige Optionen, „rsync“ kriegt es nicht hin, nicht existente Verzeichnisse bei einem Fullback in ein leeres Verzeichnis anzulegen usw…


Entweder kompiliere ich die Tools selbst aus den GNU Sources oder installiere mir diese über Portage/Darwinports/Fink… nur… funktioniert dann auch alles wie erwartet mit den bereits vorhandenen Softwares und dem System, dass die BSD Style Binaries erwartet?

Ich hab' da so meine Zweifel… daher würd' mich interessieren, ob jemand Erfahrung damit gemacht hat.

Yves
 
wenn du die anständig in /usr/local/bin packst und nicht die alten überschreibst, sollte es da keine probleme geben...
 
Ok. Ausgeführt werden dann, sofern ohne Pfadangabe angegeben, die Binaries, die in der PATH Variable hierarchisch zuerst kommen, oder?
 
ja...
in skripten schreibt man aber eh alles mit pfad angabe...
 
Ob die GNUismen tatsächlich "verbesserte" Exemplare sind wage ich mal vorsichtig anzuzweifeln.
Die GNU Programme halten sich oft nicht an die SUSv3 und die Portabilität von Skripten, die sich auf GNUische Funktion verlassen ist oftmals nicht gegeben. Yves liefert ja selbst das Beispiel mit :D.

Sicher muss jeder selbst entscheiden, ob er sie einsetzt, aber man sollte sich dann auch der möglichen Konsequenzen bewusst sein.
So generell von "besser" zu reden halte ich persönlich für unangebracht.

jm2c

btw: wie man unter mac OS X Skripten rotieren kann, kannst Du bei den periodic Skripten nachsehen.
Schöner und IMHO auch einfacher geht es mit einer netten Schleife.
 
Zu den Pfadangaben in Scripten… aus Sicherheitsgründen wahrscheinlich, oder? Damit ich einem Script keine manipulierte Executable untermogeln kann, sowie es Rootkits tun?

Bezüglich besser z.B. bei 'cp'… das Parameter 'l' für „link files instead of copying“ finde ich definitiv sinnvoll und wünschenswert, sodass diese Extrafunktionalität des GNU-Style Executable für mich als Argument für „besser“ erschließt.
 
man kann bei skripten halt nie sicher sein, dass immer die gleiche (oder überhaupt eine) PATH variable vorhanden ist...
 
maceis schrieb:
Ob die GNUismen tatsächlich "verbesserte" Exemplare sind wage ich mal vorsichtig anzuzweifeln.
Zum Vergrößern anklicken....

Juhu, bei der Gelegenheit klinke ich mich mal ein:

Wie umgeht ihr die Beschränkungen mit "ps"?

1.
Was mir ganz dolle fehlt, ist "-f": Darstellung der Prozesse als Baum, mit Abhängigkeiten.
"pstree" scheint ja nicht zu existieren.

2.
ps schneidet bei mir alle Ausgaben an der Terminalbreite ab - auch, wenn die Ausgabe in eine Pipe geht. Dadurch schlagen solche Abfragen fehl:

ps -aux | grep -i "Retrospect"

...den Retrospect.app liegt in einem so langen Unterordner, das ps das gar nicht erst ausgibt.



Will auch GNU-Tools (Und bei cp -a unterschriebe ich auch schn mal) :)
Kann man aber dank HFS+-Filesystem mit Sicherheit knicken.

Gruß,
Ratti
 
ratti schrieb:
2.
ps schneidet bei mir alle Ausgaben an der Terminalbreite ab - auch, wenn die Ausgabe in eine Pipe geht. Dadurch schlagen solche Abfragen fehl:

ps -aux | grep -i "Retrospect"

...den Retrospect.app liegt in einem so langen Unterordner, das ps das gar nicht erst ausgibt.
Zum Vergrößern anklicken....

Damit die Ausgabe nicht auf Terminalbreite abgeschnitten wird, mußt Du ein bzw. zwei "w" als Option mit ausfnehmen. Mit einem w verhält sich ps so, als ob das Terminal 132 Zeichen breit ist. Bei zwei w wird allses ausgegeben.

Also:
ps -wwaux | grep -i "Retrospect"

Gruß

Thomas
 
ratti schrieb:
...
1.
Was mir ganz dolle fehlt, ist "-f": Darstellung der Prozesse als Baum, mit Abhängigkeiten.
"pstree" scheint ja nicht zu existieren.
...
Zum Vergrößern anklicken....
Es gibt irgendwo eine Version für Mac OS X (seit mehreren Jahren). Hatte ich mal drauf, brauch ich aber nicht wirklich.

Hier - Google, erste Seite.
 
ratti schrieb:
Will auch GNU-Tools (Und bei cp -a unterschriebe ich auch schn mal) :)
Kann man aber dank HFS+-Filesystem mit Sicherheit knicken.
Zum Vergrößern anklicken....

sollte man eigentlich nicht, die haben die file routinen gepatcht in tiger, dass die resource forks etc auch mit kopiert werden. deswegen packen ja auch die ganzen unix tools die seit tiger mit.
probier es einfach mal aus....
 
oneOeight schrieb:
sollte man eigentlich nicht, die haben die file routinen gepatcht in tiger, dass die resource forks etc auch mit kopiert werden. deswegen packen ja auch die ganzen unix tools die seit tiger mit.
probier es einfach mal aus....
Zum Vergrößern anklicken....

Ja, die /originalen/ von Apple. Aber ich wollte ja, wie der Original-Frager, lieber die von GNU. Und die wissen nix von Forks. Oder?

Gruß,
Ratti
 
ratti schrieb:
Ja, die /originalen/ von Apple. Aber ich wollte ja, wie der Original-Frager, lieber die von GNU. Und die wissen nix von Forks. Oder?
Zum Vergrößern anklicken....

ich meine das wurde auf system-ebene gepatcht (sprich die unix file routinen geben die forks zurück, falls vorhanden) und nicht in den einzelnen tools...
probier es doch einfach mal aus...
 
thomastr schrieb:
Damit die Ausgabe nicht auf Terminalbreite abgeschnitten wird, mußt Du ein bzw. zwei "w" als Option mit ausfnehmen. Mit einem w verhält sich ps so, als ob das Terminal 132 Zeichen breit ist. Bei zwei w wird allses ausgegeben.
Zum Vergrößern anklicken....

Gestern stand das noch nicht in der manpage. Wieso steht das heute drin!? %-)

...weil ich mich so drauf versteift hatte, es müsse eine Umgebungsvariable sein wie COLUMNS unter Debian... das ich bei den Optionen gar nicht geguckt habe... stupid...

Danke.

Gruß,
Ratti
 
oneOeight schrieb:
ich meine das wurde auf system-ebene gepatcht (sprich die unix file routinen geben die forks zurück, falls vorhanden) und nicht in den einzelnen tools...
Zum Vergrößern anklicken....

Wie soll das gehen? Wenn ich mir ein "cp" programmiere, dann macht das halt:

öffnen quelldatei
öffnen zieldatei
read,write until EOF
schliessen quelldatei
schliessen zieldatei

Solange ich nicht n forks erwarte, kann sie mir keiner unterschieben.

Gruß,
Ratti
 
ratti schrieb:
Wie soll das gehen? Wenn ich mir ein "cp" programmiere, dann macht das halt:
Zum Vergrößern anklicken....

dann liegt das aber an dir ;)
guck halt nach ;)
wozu gibt es die sourcen?
 
oneOeight schrieb:
dann liegt das aber an dir ;)
Zum Vergrößern anklicken....

:)
Nein, ich wollte damit sagen: Was Du beschreibst, geht nicht. Man kann das nicht "irgendwie im System" managen. Das Tool muss das unterstützen.
Das mag gehen, wenn man ausschliesslich Systemroutinen verwendet, aber spätestens bei einem Tool wie rsync wäre Schluss. Das muss Forks selbst handlen.

Gruß,
Ratti
 
ratti schrieb:
:)
Nein, ich wollte damit sagen: Was Du beschreibst, geht nicht. Man kann das nicht "irgendwie im System" managen. Das Tool muss das unterstützen.
Das mag gehen, wenn man ausschliesslich Systemroutinen verwendet, aber spätestens bei einem Tool wie rsync wäre Schluss. Das muss Forks selbst handlen.
Zum Vergrößern anklicken....

ich hab gerade mal das cp von apple überflogen und das einzige, was ich da gerade auffällig gesehen habe, war der teil der den ACL kram kopiert...
und in der routine habe ich beim überfliegen jetzt nichts von forks gelesen...
die patches für das gnutar haben auch nichts mit forks drin...

wie gesagt, ich hab das noch so im kopf, aus irgendwelchen dev notes, dass die das auf system-ebene gepatcht hatten...
aber kann mich auch irren, und bin jetzt auch zu faul nach den dev notes bzw den source passagen zu suchen ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten