GNU-Tools anstatt der Standard-UNIX-Tools benutzen?

[tfc]

Hallo Leute

Bevor ich OS X hatte, habe ich vier Jahre lang Linux benutzt (Und benutze es immer noch nebenher).
Daher stammt meine Gewohnheit, viel mit der Konsole zu arbeiten.

Was mir aber beispielsweise auffällt:
Wenn ich einen Ordner löschen will, dann ist in der Konsole natürlich folgendes einzugeben:

rm -r ordner/

Klar, nix neues.

Unter Linux habe ich es mir nicht angewöhnt, das "-r" immer VOR den Ordnernamen zu setzen. Denn wenn ich beispielsweise drei Dinge löschen will und erst später bemerke, dass eins davon ein ordner ist, dann ist das mit dem GNU-rm nicht schlimm, weil ich das "-r" einfach ganz hinten anreihen kann.

Mit dem Darwin-rm geht das nicht. Jenes will das "-r" unbedingt davor haben oder verweigert ansonsten den Dienst. Jetzt liegt es nahe, mir einfach solche Tools vom GNU-Projekt unter Darwin zu kompilieren und statt den Originalen zu nutzen.

Meine Frage an die Community: Wer hat damit Erfahrungen gemacht, ob das glatt läuft?

 

[MacMark]

http://www.finkproject.org/

 

[tfc]

Danke für den Link, aber Fink habe ich längst drauf und damit habe ich Amarok, MySQL, KDE usw. installiert.

Hast Du mein genaues Problem verstanden? Ich möchte die Standardtools für das Dateihandling in der Konsole _ersetzen_ und nichts neues hinzufügen. Ich möchte, wenn ich "rm" aufrufe, nicht das Standard-"rm", das zu Darwin gehört, benutzen, sondern das GNU-"rm".

Das könnte ich tun, indem ich die datei /bin/rm auf meinem jetztigen System lösche, mir den Sourcecode der GNU-Version herunterlade, kompiliere und statt des Originals meines Systems dort hin kopiere.
Was ich wissen will, ist: Gibt das Probleme? Tut das Darwin-rm Dinge, die ich nicht bedacht habe, die das GNU-rm nicht tut, was es zu einem schlechten Ersatz macht?

 

[quarx]

Wieso eigentlich so ein Aufstand, bloß wegen der -r Option? Tipp Ctrl+A, dreimal Rechtspfeil und Du kannst es vorne einfügen.

 

[tfc]

Ctrl+a.... Das ist cool. Den kannte ich noch nicht, danke.

Nun ja, ich würde generell gerne auf die altbekannte Syntax der GNU-Tools zurückgreifen.
Der rm-Befehl und die "-r" Option waren eher ein Beispiel für die allgemeine Problematik.

 

[quarx]

Hast Du noch mehr Beispiele, interessehalber? Syntaxunterschiede zwischen verschiedenen Unixoiden sind mir bisher nur zwischen Linux und Solaris negativ aufgefallen (bei tar zum Beispiel).

Ctrl+a und Ctrl+e sind bei mir die zweithäufigsten Tastendrücke im Terminal (bash), hinter der Tab-Taste. Und dicht gefolgt von Escape+# und Ctrl+r ...

 

[tfc]

bin diese TasteX+TasteY Kombis nicht gewöhnt, da ich VI-tischist bin.

also bei "cp" ist das mit dem -r Parameter ebenso. das Tool "ps" ist auch recht anders zu bedienen. Hinzu kommt "du", welches keinen "-m" Parameter kennt, den ich aber in ein paar Skripten oft nutze.

Es ist totaler Kleinkram, ja. Aber es ist eine riesige Ansammlung von jenem. Und es betrifft ja auch nur die totalen Standardtools.

Beim Rest, wie Ettercap, unrar, cowsay ( ), usw. usf. ist ja alles gleich, weil ich die Fink-Versionen benutze.

 

[zeno]

Zu der du Sache, das einige was mir in dem Zusammenhang aufgefallen ist, das ich unter Linux bei du den riesigen --max-depth=1 Parameter benutzen muss und Unix mir das schöne -d1 gibt. Ansonsten finde ich geht das umgewöhnen recht schnell, andersrum funktionierts ja meißtens

du -m

BLOCKSIZE If the environment variable BLOCKSIZE is set, and the -k
option is not specified, the block counts will be displayed in
units of that size block. If BLOCKSIZE is not set, and the -k
option is not specified, the block counts will be displayed in
512-byte blocks.

 

[quarx]

Die Frage ist natürlich, wer hier standardisiert ist. Mac OS X ist vollständig POSIX-konform, was eine Linux-Distribution nicht von sich behaupten kann. Nach der POSIX-Spezifikation dürfen die Argumente bei den Standardtools wie rm halt nur vor den Operanden stehen und nicht dazwischen.

Der Syntaxunterschied bei ps ist mir auch aufgefallen, stimmt. Was bewirkt die -m Option bei du? Danke, zeno.

 

[tfc]

du -m
(BLOCKSIZE ...)

Ja, meine Skripte wurden alle um sowas ergänzt nach meiner Migration auf die neue Apple-Karre.

Nach der POSIX-Spezifikation dürfen die Argumente bei den Standardtools wie rm halt nur vor den Operanden stehen und nicht dazwischen.

Ja, das stimmt natürlich. Trotzdem empfinde ich es als ungemein praktisch, wenn das Programm mit durcheinander geworfenen Parametern arbeiten kann. Wenn ich selbst Programme oder Scripte schreibe, dann sorge ich dafür, dass man dort ebenfalls nicht auf die Reihenfolge achten muss. Kompliziert zu implementieren ist sowas ja nicht.

 

[Hobbes_]

Ich habe es immer eher als Sicherheitsfeature gesehen und nicht als Unwillen der Programmierer, es nicht zu implementieren. Doch wer weiss?

 

[MacMark]

… indem ich die datei /bin/rm auf meinem jetztigen System lösche, mir den Sourcecode der GNU-Version herunterlade, kompiliere und statt des Originals meines Systems dort hin kopiere. …

Das ist nicht klug. Damit änderst Du als Seiteneffekt interne Skripte von OS X. Du kannst jedoch Deinen $PATH in den Bash-Startdateien so setzen, daß Dein Wunsch-rm vorne steht.

 

[Rastafari]

Trotzdem empfinde ich es als ungemein praktisch, wenn das Programm mit durcheinander geworfenen Parametern arbeiten kann.

Andere halten das hier für ziemlich heimtückisch:
GNU

> ls
[COLOR="Blue"]file_1  file_2  folder_1  -f  -r[/COLOR]
> rm f* -f -r
> ls
[COLOR="Blue"]-f  -r[/COLOR]
>

BSD

> ls
[COLOR="Blue"]file_1  file_2  folder_1  -f  -r[/COLOR]
> rm f* -f -r
> ls
>

Das ist des Eisbergs freundliche Spitze.
"Happy Titanic - now shipping..."

 

[tfc]

tfc@gnu ~/testdir $ ls
-f  -t  file1  file2
tfc@gnu ~/testdir $ rm f* -f -r
tfc@gnu ~/testdir $ ls
-f  -t
tfc@gnu ~/testdir $ rm ./-*
tfc@gnu ~/testdir $ ls
tfc@gnu ~/testdir $

Wenn ich eine Strichliste führen würde, auf der ich jeweils abhake, wann ich ungeordnete Parameter verwende und wann ich Dateien lösche, die genauso heißen, wie Parameter, dann würde der Zettel auf der Seite des zuerst erwähnten Ereignisses viel viel schneller voll werden, was die Interpretation der Parameter auf GNU-Art für mich persönlich sofort legitim und sogar praktischer macht.

Wenn man es nicht anders lösen könnte, dann wäre es eine böse Überraschung, da hast Du Recht.
Das ist natürlich nicht noobgerecht, aber diese Eigenschaft gehört nicht in meinen Kriteriensack, den ich immer einstecke, wenn ich auf Softwarejagd gehe.

tfc@gnu ~/testdir $ cd ..
tfc@gnu ~ $ rm testdir/ -r

 

[minimaclix]

Ich denke, Du suchst das hier: http://coreutils.darwinports.com/
Die Macports installieren ja nach /opt usw., also muss man die BSD Utilities nicht überschreiben (sollte man wohl auch nicht). Dann muss man noch die Enviroment (PATH, MANPATH) anpassen, so dass /opt vor /usr kommt. Wenn man von Linux kommt ist das wahrscheinlich schon sehr praktisch, da man an die GNU-Tools gewöhnt ist, außerdem sind sie viel aktueller* und auch für Intel gebaut (da ja selbst kompiliert), wobei das wohl keinen Unterschied macht. Da ich bisher ausschließlich fink verwende, habe ich es aber noch nicht getestet.
* (auf Mac OS X 10.4.10) $ bash -version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Copyright (C) 2002 Free Software Foundation, Inc.

Falls Du nur eine aktuelle bash haben möchtest, kannst Du sie auch einfach selbst kompilieren und nach /usr/local installieren. Auch dann muss der Pfad angepasst werden.

In beiden Fällen muss die Shell noch in /etc/shells eingetragen werden.

 

[minimaclix]

Zur Diskussion ob das Verhalten der GNU-Tools besser oder schlechter ist, glaube ich, dass Richard Stallman und Kollegen sich schon was dabei gedacht haben, die nachgebauten Unix-Tools etwas zu verändern/zu erweitern. Dabei wurde bestimmt auch an effektiveres Arbeiten gedacht. Was man nun besser oder schlechter findet, ist wohl eher eine Frage der Philosophie (siehe Vi vs. Emacs).

 

[Hobbes_]

Zur Diskussion ob das Verhalten der GNU-Tools besser oder schlechter ist, glaube ich, dass Richard Stallman und Kollegen sich schon was dabei gedacht haben, die nachgebauten Unix-Tools etwas zu verändern/zu erweitern. Dabei wurde bestimmt auch an effektiveres Arbeiten gedacht. Was man nun besser oder schlechter findet, ist wohl eher eine Frage der Philosophie (siehe Vi vs. Emacs).

Selbstverständlcih haben sie sich was dabei gedacht. Doch auch die Programmierer der restriktiveren tools haben sich etwas gedacht (nämlich Sicherheit!). Die möglichen probleme werden schön an Rastafaris Beispielen gezeigt...

Doch: Chacun à son goût.

 

[tfc]

Selbstverständlcih haben sie sich was dabei gedacht. Doch auch die Programmierer der restriktiveren tools haben sich etwas gedacht (nämlich Sicherheit!). Die möglichen probleme werden schön an Rastafaris Beispielen gezeigt...

Ich habe keine Probleme gesehen. Wer BSD gewohnt ist, muss in einer GNU-Umgebung lediglich umdenken. Wer's gewohnt ist, arbeitet ganz normal mit dem, was Du an Rastafaris Beispielen Sicherheitsrisiko nennst.

 

[minimaclix]

Anscheinend beheben die GNU-Tools auch die Unicode-Probleme des Mac OS X Terminals:
http://www.rift.dk/news.php?item.7.6
Das wäre doch mal was. Wenn dann noch Subversion mit Umlauten gehen würde
(http://blog.thylmann.net/2007/06/05/os-x-terminal-internationalization/), könnte man richtig inter-operabel arbeiten.

 

[MacMark]

Was für Unicode-Probleme? Ich habe keine.