GNU Versionen in FreeBSD?

ninti

Well-Known Member
Hallo liebe Leute :)

Ich lese mich etwas ins Bash ein und lese immer wieder, dass Kommandos wie z.B. tail ihre eigene GNU Version haben, welche weitere und meist bessere Features besitzen als die "Standardanwendung".
Besitzt FreeBSD die auch?
So weit ich weiß, hat FreeBSD auch ihre eigene Versionen, ist das "noch" so?

Bleiben wir bei tail, kann ich damit in FreeBSD, auch weitere Dateien "monitoren"?

Grüße
 
FreeBSD hat ein eigenes Basissystem welches iA eigene Versionen der entsprechenden Tools bereit hält. Das GNU-Userland hat einige Optionen hinzugefügt oder verändert was über POSIX hinaus geht (und daher nicht zu allen anderen Systemen - z.B. FreeBSD) kompatibel sind. POSIX gibt den Standard vor, was dazu führt, dass z.B. Scripte die auf GNU-Linux geschrieben wurden (und diese erweiterten Optionen nutzen) nicht auf jedem anderen POSIX-System laufen.

Kurz gesagt: Ja FreeBSD hat eigene Versionen dieser Tools und wird die sicher auch beibehalten (alleine schon um sich nicht unnötig GPL einzufangen). Einige GNU-Tool stehen aber afaik in den Ports (oder als Pakete) zur Verfügung, so dass du diese austesten kannst.
 
GNU-Tools haben in der Regel mehr Features und sind oft so langsam, dass man sie in Skripten nicht verwenden kann. Eine populäre Ausnahme ist grep. Das ist ein GNU-Tool das im Vergleich zu anderen grep Implementierungen schnell ist.
 
Das "grep" in FreeBSD ist auch das von GNU.
Allgemein geht es im Basissystem mal so - mal so, je nachdem, ob sich schon ein Freiwilliger für eine Nicht-GNU-Implementierung gefunden hat.
 
Was meinst du damit?
$ tail -f ?

Rob
Gegenfrage: Was meinst DU damit??
Ja klar gehts auch um tail -f, aber man kann es auch ohne Optionen starten.
Mit monitoren meinte ich verwenden so wie:
Code:
tail -f datei1 datei2

Oooookay. Vielen lieben Dank!
Habt ihr vielleicht paar deutsche Texte für SH?
Also Shell Programmierung.

Viele Grüße
 
Also ich bin mit dem oReilly-Buch am Werke und finde es an sich recht gut. Hab zwar die englische Version aber es gibt mein ich auch eine deutsche Version.
 
Gegenfrage: Was meinst DU damit??
Ja klar gehts auch um tail -f, aber man kann es auch ohne Optionen starten.
Mit monitoren meinte ich verwenden so wie:
Code:
tail -f datei1 datei2

dmesg | tail -f

zum Beispiel gibt die letzten Zeilen von dmesg aus.
Der GNU Befehl beendet sich dann aber nicht, sondern lauscht weiter auf kommende Änderungen der Ausgabe von dmesg.
Das kann recht praktisch sein, weil man Meldungen quasi live verfolgen kann, während in FreeBSD das Kommando ständig wiederholt werden müsste.
Grundsätzlich haben wir mit dem Kompatibilitätsmodus ja auch die Möglichkeit, Linux zu nutzen und dann findet sich unter /usr/compat/linux/usr/bin/tail "das andere tail".
Wie man das aber auf die aktuelle FreeBSD dmesg anwenden könnte, um solch einen tail -f wie im Linux zu erzeugen, habe ich keinen Schimmer. dmesg ist ja da nicht eine Meldung des zugehörigen Linux-Kernels. Deshalb wird bei mir zwar das verhalten so nachgeahmt, wie bei einem GNU tail, aber es laufen keine Aktualisierungen auf.
 
Kleine Frage, was ist mit dem gcc?
Muss ich dann die Sourcecodes für FreeBSD anpassen, wenn ich es für Linux programmiert habe??
 
Kleine Frage, was ist mit dem gcc?
Muss ich dann die Sourcecodes für FreeBSD anpassen, wenn ich es für Linux programmiert habe??

Das sollte primär nicht von deinem Compiler, sondern von den verwendeten Schnittstellen abhängen.
Es kommt darauf an, wie du den Quelltext geschrieben hast. In der Theorie sollte es ausreichen, wenn du gegen POSIX-Schnittstellen programmiert hast.
Ansonsten halte ich es für guten Stil, seinen Code ab und an mit anderen Compilern zu beackern, um zu verhindern, dass man kein portables C mehr schreibt, sondern nur noch ein von einem einzigen Compiler unterstützten Subset davon (wie beispielsweise der Linux-Kernel *hüstel*).

Wenn du also nicht ganz abenteuerliche Dinge getan hast, dann solltest du maximal einige Header-Dateien anpassen müssen, und eventuell einige Bibliothekspfade im Buildmanagementsystem (a.k.a. den Makefiles).
 
Danke für die Antwort!
Gibts eigentlich dieses Framework für/unter C, womit man auch viele BS ansteuern kann?
 
Was für ein Framework meinst du denn? Wenn du rein POSIX-Kompartiblel programmierst dann sollte dein Code (ohne riesen Anpassungen) auf POSIX-Sytemen laufen, wie goblin ja auch schon sagte. Ein reines "HelloWorld" das bissl printf macht und sonst nix sollte fast überall übersetzen.
 
POSIX-Kompartiblel:
Bis welche Version von C ist es denn nun POSIX-Kompartiblel?
Bis C99 oder schon C90?

Ist das nicht egal welche C Version es ist, Hauptsache ich nehme POSIX-Kompatible Bibliotheken??

Danke für die Antworten!
 
Du siehst es zu theoretisch. C ist dreimal standardisiert worden. In 1989 / 1990, 1999 und 2011. Wenn Kompatibilität mit VisualStudio [1] keine Rolle spielt, nimmt man in der Praxis meist die 1999er Variante. Beziehungsweise eine Untermenge davon. Ganz einfach, da sie gegenüber C89 einige deutliche Verbesserungen enthält und auf der anderen Seite C11 noch sehr jung ist. Zudem halten sich die praxisrelevanten Änderungen in C11 sehr in Grenzen. Je nach dem wie portabel man es halten möchte, kann man noch compilerabhängige Erweiterungen dazu nehmen, wobei es in meinen Augen nur in seltenen Fällen Sinn hat.

POSIX ist nun ein loser Standard der definiert, welche Interfaces ein kompatibles System bereitstellen soll. Es greift mit anderen Standards und Pseudo-Standards wie der berüchtigten Single UNIX Specification oder dem 4.4BSD-Interface zusammen. Die Liste ist lang. Es geht damit los, welche Tools es geben muss und welche Schalter mit welcher Funktion sie besitzen müssen. Auf C-Ebene sind vor allem Funktionen und Syscalls interessant. Aber in der Praxis gibt es kaum ein System, was POSIX vollständig implementiert. Dazu kommt, dass POSIX allein recht schlank ist und viele Systeme Dinge aus durchaus gutem Grund anders bzw. besser machen möchten. Außerdem gibt es eine ganze Reihe POSIXe... POSIX-Kompatiblität ist also nur eine sehr schwammige Sache. Zu guter Letzt sind POSIX und die C-Standards teilweise gegensätzlich. Z.B. ist dlopen() bei strenger Lesung des C-Standards nicht standardkonform implementierbar.

Aber. Die Zeiten der Unix-Kriege sind lange vorbei und die heute relevanten Systeme (Linux, OS X, die BSDs) sind sich so ähnlich, dass diese Überlegungen kaum eine Rolle spielen. Wenn das Programm eine vernünftige Architektur und sauberen Code hat, ist die Portierung zwischen diesen Systemen in den meisten Fällen trivial und eine Sache von einem Nachmittag. Daher mache dir nicht so viele Gedanken. Nehme C99 (am besten mit -std=c99 -Wall -Werror, -pedantic ist sinnvoll aber schwer durchzuhalten), wenn du Bibliotheksfunktionen nutzt, schlage kurz nach ob die gängisten Systeme sie haben uns sei glücklich.

Wenn du auf Windows willst und nicht auf MinGW oder sogar Cygwin zurückgreifen willst, wird die Sache so oder so schmutzig und verlangt bei sauberer Umsetzung mehr Hirnschmalz, als man als Anfänger aufbringen kann. Denn dann brauchst du zwangsläufig Plattform-Backends, eventuell Wrapper-Funktionen oder Makros und all diese Schmutzigkeiten.

1: VisualStudio war lange auf reines C89 beschränkt. Inzwischen bewegt sich Microsoft aber in Richtung eines zumindest teilweisen C99-Supports. Allerdings hat Microsoft eigene Ansichten über die Implementierung der Bibliothek.
 
-std=c99 -Wall -Werror, -pedantic

kannst du das genauer machen?
also zb clang -o programm ....

ohne , -pedantic geht das gut. Kenn mich da nicht aus.

Ich frage mich eigentlich auch, was wenn ich ein Programm schreibe, dass für Linux ist, aber auf einen FreeBSD Server zugreift. Geht das dann ganz normal mit der "Linux Version"?
Oder muss ich dazu noch die nötigen Bibliotheken für FreeBSD einbinden und benutzen? Würde es dann noch in Linux funktionieren?
Ist dann der Einsatz für Plattform-Backends ? :)

Hab da jetzt echt n fettes Fragezeichen auf der Stirn. :D
Hoffe ich lauf jetzt nicht im Kreis und schreib immer das gleiche. :D
Dann bitte Geduld aufbringen und nochmal erklären - danke schööön.

Windows interessiert mich da eh am wenigsten.
 
Ich glaube du musst dich da noch etwas einlesen ;)

Also die Optionen kannst du eigentlich in der Manpage nachlesen oder für clang auch gerne hier: http://clang.llvm.org/docs/UsersManual.html

Das Programm das du schreibst muss auf dem System auf welchem es läuft übersetzen können und die nötigen Schnittstellen zum System nutzen können. Das ist aber völlig unabhängig von Client/Server-Architekturen. Das hängt wiederum davon ab über welches Protokoll die beiden Systeme kommunizieren. Wenn du von Linux und FreeBSD sprichst gehe ich mal davon aus, dass du die beiden Systeme per Netzwerk verbinden willst. Dann müssen nur Server und Client beide das selbe Protokoll über das Netzwerk sprechen. Das so ähnlich wie wenn das eine Programm seine Daten in eine Datei schreiben kann und das Andere die Daten aus der Datei lesen. Sprich beide müssen wissen wie die Daten auszusehen haben (nur dass es dann eben keine Datei ist sondern ein Netzwerk über das die Daten ausgetascht werden).
Siehe Webseiten. Es ist egal auf welchem System ein Webserver oder ein Browser läuft. Die müssen halt HTML-Seiten anbieten, oder darstellen können.
 
Rakor sagt es. Aber trotzdem, der Vollständigkeit halber: Das Komma in meinen Optionen war als Trenner zwischen den Halbsätzen gedacht. Nicht als Teil der Optionen. :) -std=c99 zwingt des Compiler C99 zu nutzen. Erzwingt man den Standard nicht, nutzt der GCC den Dialekt gnu99 und Clang gnu11. Wobei beide Compiler die Dialekte leicht anders implementieren. -Wall schaltet einen Großteil der Warnungen ein. Die Compiler können noch weitaus mehr Warnungen erzeugen, die allerdings nicht unbedingt sinnvoll oder hilfreich sein müssen. -Wextra wäre die nächste Steigerung, aber das ist Overkill und man will es im Normalfall nicht. -Werror lässt Warnungen wie Fehler behandeln, d.h. eine Warnung führt zum Abbruch. Aus psychologischen Gründen sehr gut, denn solange die Warnung da ist, baut das Programm nicht. Verhindert schnelles rumgefrickel. -pedantic sorgt dafür, dass der Compiler äußerst pedantisch wird. Er folgt dem Standard nahezu wortwörtlich und weißt auch allgemein akzeptierte und im Großen und Ganzen zulässige Konstrukte zurück. In der Realität kann man -pedantic oft nicht durchhalten, aber man kann es solange nutzen, wie es möglich ist.
 
Ich mag es übrigens, bei clang wirklich alle Warnungen anzuschalten, und dann lediglich die einzelnen Warnungen, die ich nicht haben möchte, explizit wieder zu deaktivieren.
Ich nutze beispielsweise momentan:
Code:
CFLAGS+=-Wpedantic \
    -Weverything \
    -Wno-documentation \
    -Wno-padded \
    -Wno-reserved-id-macro \
    -Wno-vla \
    -Werror
in einem Makefile. Das ist allerdings nicht mehr zwischen gcc und clang portabel, was mir momentan aber egal ist ;)

Bezüglich Microsoft etwas Hintergrund: Die wollen kein C mehr kennen und haben alles ab C89 ignoriert. Da C++11 aber große Teile des C99-Standards übernommen hat müssen sie jetzt ihre über Jahre gewachsene Infrastruktur anpassen. Sie haben einige Funktionen äquivalent zu C99, aber beispielsweise anders parametrisiert, so dass sie dem Standard nicht direkt entsprechen. Und Rückwärtskompatibel wollen sie dabei auch noch bleiben…

Ansonsten sehen deine Fragen für mich so aus, als seist du noch ein Programmieranfänger, und da gleich mit C in die Netzwerkprogrammierung einzusteigen finde ich schon etwas… ambitioniert. Da musst du wirklich sehr viel mehr von Hand machen als bei vielen jüngeren Alternativen. Wenn du also nicht gerade hochzuverlässige Netzwerkdienste schreiben möchtest (was du als Anfänger vermutlich auch nicht schaffen würdest), dann würde ich dir vielleicht zu Beginn zu Python oder Go raten, damit kommst du vermutlich schneller und einfacher zum Ziel.
Wenn es sich aber nur um ein Lernprojekt zum Kennenlernen von System, Sprache und API handelt, dann finde ich dass das der richtige Weg ist: am meisten lernt man, wenn man Dinge ausprobiert und Fehler macht, diese findet und behebt.
 
Ansonsten sehen deine Fragen für mich so aus, als seist du noch ein Programmieranfänger, und da gleich mit C in die Netzwerkprogrammierung einzusteigen finde ich schon etwas… ambitioniert.
Ich will noch viel mehr ;)
Ich wollte mich nur vorerst informieren, wie das eigentlich so ist, wenn ich einen Code auf Linux programmieren und es z.b. auf Alpha dann auch über Netzwerk funktioniert. Da muss ich gleich wissen, welchen Standard ich verfolgen muss und am Anfang finde ich ist das A und 0.

Ich will ja auch später Python "lernen", aber ich möchte schon mit C anfangen, da ich auch "nicht so lange zu leben habe", um auch meine Fantasien und Wünsche zu ermöglichen. :D :D
Und das ohne Studium.
Ich möchte keine Netzwerkdienste schreiben. ;)
Und dazu, was ich vor habe eignet sich selten Python oder Perl, was ja auch nicht so schlecht ist.
Außerdem stehe ich irgendwie aufs Kompilieren als auf Interpretieren. Ist irgendwie ein Gefühl von Macht dabei ^^

Microsoft: Hey, die wollen immer ihren eigenen Standard haben, kriegen sie aber nicht. :D
Genauso wie bei IE.

Woher hast du eigentlich deine CFLAGS kopiert?
Kann ich das in den Sourcecode einkopieren und er kompiliert es mit den Optionen? ^^
Es wäre schön zu wissen, was sie machen, ohne jetzt wieder Links zu wälzen.
Kurze Beschreibung wäre toll.

Danke für deine Antwort!
 
Zurück
Oben