compilieren in C mit gcc

[below]

... heißt das ja noch lange nicht, daß das OS auch case-insensitive ist. Wie alle mir bekannten Unixe ist daher Mac OS X stets case sensitive, verhält sich.

Nein, das OS verhält sich so wie das FS. Also auf "altem HFS":

% echo `Date` > test.txt
% cat Test.txt
Thu Jan 12 12:12:29 CET 2006

Wie funktioniert das? Würde ich bei mir gerne auch machen.

Für Einsteiger ist das nämlich imho verwirrend und gefährlich

Das mit den Einsteigern sehe ich nicht so, die geben Dateinamen selten ein, wenn sie nicht müssen. Mach ich ja noch nicht mal -- wozu hat man denn Filename completion.

Aber eben für Profis: Du änderst Gross/Kleinschreibung einer Datei, und schon findet der Apache auf Linux oder das SCM sie nicht mehr. Das ist mir Arbeit und ärger verbunden.

Naja, hier kommt die schlechte Nachricht: Soweit ich weiss, musst Du die Platte mit der Option formatieren. Im Nachhinein kenne ich keine Möglichkeit.

Alex
EDIT: Hatte Zitate und meinen Text vermischt

 

[Incoming1983]

Nein, das OS verhält sich so wie das FS. Also auf "altem HFS":

% echo `Date` > test.txt
% cat Test.txt
Thu Jan 12 12:12:29 CET 2006

Seltsam, wieso funktioniert dann die Filename completion nicht?
in deinem Beispiel:
"cat T<tab>" würde nicht funktionieren..

Bzw. die von mir ganz am Anfang monierte Syntax müßte auch gehen..

Das mit den Einsteigern sehe ich nicht so, die geben Dateinamen selten ein, wenn sie nicht müssen. Mach ich ja noch nicht mal -- wozu hat man denn Filename completion.

naja, ich erstelle eine "HalloWelt.txt" und danach eine "hallowelt.txt". Dann hab ich meine erste Datei aber überschrieben, obwohl ich, als Anfänger, ja davon ausgehe, daß es zwei Dateien geben müßte.

Aber eben für Profis: Du änderst Gross/Kleinschreibung einer Datei, und schon findet der Apache auf Linux oder das SCM sie nicht mehr. Das ist mir Arbeit und ärger verbunden.

Naja, aber das kennt man doch ;-). Wer kommt schon auf die Idee, die Datei anders zu verlinken, als sie heißt?

Naja, hier kommt die schlechte Nachricht: Soweit ich weiss, musst Du die Platte mit der Option formatieren. Im Nachhinein kenne ich keine Möglichkeit.

Mist, das bedeutet viel Arbeit :-(

 

[below]

Seltsam, wieso funktioniert dann die Filename completion nicht?

Filename completion ist ein feature der Shell, nicht vom OS

naja, ich erstelle eine "HalloWelt.txt" und danach eine "hallowelt.txt". Dann hab ich meine erste Datei aber überschrieben, obwohl ich, als Anfänger, ja davon ausgehe, daß es zwei Dateien geben müßte.

Das würde aber bedeuten, dass der "Anfänger" die Dateien nicht aufmacht, sondern z.B. erst eine Datei "diesda.txt" aufmacht, und sie dann - ohne Überrpüfung! - als "hallowelt.txt" abspeichert.

Denn bei vi hallowelt.txt bekommt er ja HalloWelt.txt.

Nee nee, und Leute die beim Mac im Terminal rummachen, dürfen sich bei mir nicht hinter dem Feigenblatt "Anfänger" verstecken
Da halte ich es mit alten Apple Handbüchern: "If you do not know what an Interrupt or a Reset is, you do not need this switch"



Alex

 

[Incoming1983]

Filename completion ist ein feature der Shell, nicht vom OS

Stimmt auch wieder..

Nee nee, und Leute die beim Mac im Terminal rummachen, dürfen sich bei mir nicht hinter dem Feigenblatt "Anfänger" verstecken

Das Terminal ist nunmal der standard-weg um mit dem OS und mit Programmen zu interagieren.
Und ich denke, die meisten Unix Anfänger fangen mit Mac OS X an.

Da halte ich es mit alten Apple Handbüchern: "If you do not know what an Interrupt or a Reset is, you do not need this switch"

Die sind ja auch grottig. Genauso wie die von MS heute.

Wer ein gutes Handbuch sehen will, der schaut sich z.B. das von MS-DOS 5.0 an. Ca. 600 Seiten (inkl. Anhang) und alles dokumentiert.

 

[below]

Die sind ja auch grottig. Genauso wie die von MS heute.

Wer ein gutes Handbuch sehen will, der schaut sich z.B. das von MS-DOS 5.0 an. Ca. 600 Seiten (inkl. Anhang) und alles dokumentiert.

Nein, das sehe ich anders. Warum soll ich Leuten Seitenlang erklären was ein ISRC oder ein UPC/EAN Code ist?

Da sage ich auch: If you do not know what an ISRC is, you do not need it. Die, die es brauchen, wissen was das ist. Und für alle anderen ist es nur Ballast. Die Kunst besteht auch darin zu wissen, was man den Leuten nicht sagen muss.

Finde ich

Alex

 

[Konze]

ich habe mir für compilen nen Applescript geschrieben muss man net soviel tippen

 

[below]

ich habe mir für compilen nen Applescript geschrieben muss man net soviel tippen

* STOP! *

Du solltest nicht (jedenfalls nicht ohne Grund) anfangen, Deine eigenen Build-Systeme zu bauen!

Schau Dir lieber existierende Werkzeuge, wie z.B. Xcode (OS X spezifisch) oder make (1L) an. Ein einfaches Makefile für Deinen Zweck sieht so aus:

# Das Projekt ist Test. Es ist abhängig von der Datei test.o
# In der zweiten Zeile steht, was man machen muss, um test
# zu bekommen wenn man test.o schon hat
test : test.o
gcc -o test test.o

# OK, aber wie bekommt man test.o? Das steht hier:
test.o : test.c
gcc -c -o test.o test.c

# gib make clean ein, um dieses hier auszulösen
clean :
rm test.o test


Gruss

Alex

 

[Incoming1983]

Da sage ich auch: If you do not know what an ISRC is, you do not need it. Die, die es brauchen, wissen was das ist. Und für alle anderen ist es nur Ballast. Die Kunst besteht auch darin zu wissen, was man den Leuten nicht sagen muss.

Weil du nicht weißt, was die Leute wissen müssen.
Erstens zum arbeiten, und zweitens, um zu lernen.

Beispiel:
User: "Mein Windows ist lahm".
User recherchiert, schaut sich im Taskmanager Prozesse, Memusage und Swapfileusage an.
Er merkt: "Die Speicherverwaltung ist doof, der Cache ist ganz groß, und er swapped dafür Programme aus dem aktiven Ram auf die Platte, kein Wunder, daß Windows so langsam ist".
Er kommt auf die Idee: "Bevor ich da jetzt lang rumfummel, beschränke ich die maximale Cache Größe einfach".
Unter DOS/Win3.x:
DOS 5.0 Handbuch auf, nach "smartdrive" im index gesucht, config.sys (bzw. autoexec.bat ab 6.0) editiert, neu gestartet, fertig. Alles dokumentiert.
Unter Windows9x:
Nix mit Doku. In diversen Foren gesucht, irgendwann mal auf eine Windows-Geheimseite gestoßen, wo es erklärt war. In der Registry den richtigen Key gesucht (ggf. noch angelegt), Windows neu gestartet, fertig. Doku war schlecht, Registry ist gegenüber config.sys/autoexec.bat unübersichtlich, aber es ging doch noch. Auch für einen DAU, der sich mit WIn9x noch nicht so auskennt.
Windows XP:
hab ich bis heute noch nicht rausgefunden, wie es geht. Und das trau mal einem DAU zu. Früher hat er nur das Handbuch lesen müssen.. :-(

Und die Apple Handbücher sehen genauso schlimm aus, wie die von Windows XP. Wie man eine CD einlegt oder das Netzteil anschließt, das muß man nicht dokumentieren.
Und da wunderts mich auch nicht, daß die Leute keine Handbücher mehr lesen. Steht ja nix verwertbares drin.

Bei Suse gabs (zumindest früher) auch noch ein ordentliches Installations-Handbuch, wo die ganzen Linux bzw. Unix Basics halbwegs erklärt waren..

Tatsache ist wohl auch, daß MacUser die Unixuser sind, die am wenigsten mit ihrem System vertraut sind (soll keine Beleidigung sein). Apples Dokumentationspolitik tut da ihr übriges dazu.

 

[below]

Weil du nicht weißt, was die Leute wissen müssen.
Erstens zum arbeiten, und zweitens, um zu lernen.

...

Tatsache ist wohl auch, daß MacUser die Unixuser sind, die am wenigsten mit ihrem System vertraut sind (soll keine Beleidigung sein). Apples Dokumentationspolitik tut da ihr übriges dazu.

OK, aber wenn ich Dokumentation für eine Software schreibe (und 90% der User rufen lieber im Support an, als das ganze mühsam geschriebene Handbuch zu lesen -- am liebsten möchte man da "RTFM!" in den Hörer brüllen) dann ist es nicht wirklich meine Aufgabe, Hintergründe zu erklären.

Das von Dir beschriebene Besipiel ist fies. Aber ich kann ein Handbuch auch mit einer kleinen Theroie der Elektrotechnik beginnen. Da können die User auch was lernen

Alex

 

[Incoming1983]

OK, aber wenn ich Dokumentation für eine Software schreibe (und 90% der User rufen lieber im Support an, als das ganze mühsam geschriebene Handbuch zu lesen -- am liebsten möchte man da "RTFM!" in den Hörer brüllen) dann ist es nicht wirklich meine Aufgabe, Hintergründe zu erklären.

Nein, das nicht. Sollte aber so sein, daß man ganz klar auch Schlagwörter und Verweise zum weitergoogeln hat.

Z.B. wird afaik nirgends in den Systemeinstellungen erwähnt, daß die Firewalleinstellungen ein Frontend zu ipfw ist.
Eine kleine Bemerkung: "Dies ist ein Frontend für ipfw, für weitere Informationen und Einsatzmöglichkeiten empfehlen wir: http://www....)" wäre imho sehr hilfreich.

Das von Dir beschriebene Besipiel ist fies. Aber ich kann ein Handbuch auch mit einer kleinen Theroie der Elektrotechnik beginnen. Da können die User auch was lernen

Das sollten die User aus der Schule kennen ;-)
(bzw. aus der Ausbildung/Studium)

 

[below]

Z.B. wird afaik nirgends in den Systemeinstellungen erwähnt, daß die Firewalleinstellungen ein Frontend zu ipfw ist.
Eine kleine Bemerkung: "Dies ist ein Frontend für ipfw, für weitere Informationen und Einsatzmöglichkeiten empfehlen wir: http://www....)" wäre imho sehr hilfreich.

Ich weiss nicht, was Dein Hintergrund ist. Aber das wäre alles andere als "Mac Like". OS X ist nicht Linux. Der normale Benutzer muss das nicht wisenn. ("Was, huh, ipfw, ist das eine Krankheit?")

Und für die Profis gibt es andere Bücher. Das Handbuch des Mac ist nicht für Programmierer und Unix User gemacht. Und muss es auch nicht sein.

Findet

Alex

 

[Incoming1983]

Ich weiss nicht, was Dein Hintergrund ist. Aber das wäre alles andere als "Mac Like". OS X ist nicht Linux. Der normale Benutzer muss das nicht wisenn. ("Was, huh, ipfw, ist das eine Krankheit?")

Eben deshalb gibts ipfw (aus BSD) und nicht iptables ;-)

Sollte ein normaler User eine Firewall einsetzen wollen, sollte er wissen, was ipfw ist. Hingegen die Oberfläche in den Systemeinstellungen dient der reinen Bequemlichkeit.

Und für die Profis gibt es andere Bücher. Das Handbuch des Mac ist nicht für Programmierer und Unix User gemacht. Und muss es auch nicht sein.

Jeder Mac User ist nunmal ein Unix User. Daher sollte das OS auch dokumentiert sein, gerade so einfache Dinge wie cp, man, mv, rm, ssh, ...
War ja früher sogar bei MS Handbüchern standard (copy, xcopy und Co. sind im DOS 5.0 Handbuch gut geschrieben - das hab ich als Grundschüler und Computer Noob sogar begriffen).

Klar, für Developer ist das nochmal ne andere Sache, dafür gibts ja auch die ADC.
Wobei auch der normale Nutzer grundlegende Dinge verstehen sollte, wird doch viele Software (auch) im Quellcode distribuirt.

 

[below]

Jeder Mac User ist nunmal ein Unix User. Daher sollte das OS auch dokumentiert sein, gerade so einfache Dinge wie cp, man, mv, rm, ssh, ...

Das ist ein Witz, ja?

Alex

 

[Incoming1983]

Das ist ein Witz, ja?

Alex

Nein. Mac OS ist seit X ein Unix...ist doch mit der wichtigste Grund, auf Mac umzusteigen ;-)

Seitdem gibts viel mehr Software und ein (halbwegs) gewohntes OS, mit einem Windowsmanager, der Windows, KDE und Gnome in den Schatten stellt.

Ich hab mein pb und mein mac mini handbuch nur kurz angeschaut, als Kind habe ich aber richtig lange in dem DOS Handbuch geschmöckert. War echt gut gemacht.

 

[below]

Nein. Mac OS ist seit X ein Unix...ist doch mit der wichtigste Grund, auf Mac umzusteigen ;-)

Klar, aber die Leute, für die das ein Grund ist können auch man pages lesen.

Sollen wir mal eine Abstimmung in der Bar aufmachen, wer findet das "so einfache Befehle wie mv, cp und ssh" im Handbuch erklärt werden müssen?

Nein, OS X würde seine Schönheit verlieren, wenn der Unterbau - den ich sehr schätze - sichtbar würde. Und für den Unterbau gibt es tolle Bücher - auch und gerade für Anfänger - von O'Reilly

Aber das ist sicher Ansichtssache

Alex

 

[Incoming1983]

Klar, aber die Leute, für die das ein Grund ist können auch man pages lesen.

Natürlich - aber ein gedrucktes Buch ist doch was schönes ;-).
Klar ist Mac OS X in erster Linie OEM, und da wird halt gespart, aber zumindest die Retail-Version kann man ja noch hübsch aufmachen für den Preis. SuSE z.B. machts ja auch..

Sollen wir mal eine Abstimmung in der Bar aufmachen, wer findet das "so einfache Befehle wie mv, cp und ssh" im Handbuch erklärt werden müssen?

Dafür würde ich ein Einführungsbüchlein machen..

Nein, OS X würde seine Schönheit verlieren, wenn der Unterbau - den ich sehr schätze - sichtbar würde. Und für den Unterbau gibt es tolle Bücher - auch und gerade für Anfänger - von O'Reilly

Naja, der ist doch sichtbar.. ;-)
Ich glaub, ich könnte Mac OS 9 nix abgewinnen...

Und ich denke, so ein Buch sollte dabei sein, zumindest in der Retail Version.

Aber das ist sicher Ansichtssache

Ja, das stimmt wohl..

Wie gesagt, für mich war es mit einer der Gründe zu wechseln:
- echtes Unix (somit ein gewisses "ich bin zuhause" gefühl)
- schöne GUI
- gute Hardwareintegration (nix mit Kernel patchen, neu compilen, verschiedene Module ausprobieren wie unter Linux)

 

[wegus]

Mac OS X hat den großen Bonus das erste UNIX zu sein das die Technik derart vor dem User kapselt, daß auch Musiker und Grafiker damit klarkommen. Die LINUX Welt schreit nach Desktop-Linuces und Apple hat sie schon. So einfach ist das. Wir können alle die shells nutzen, sprechen Perl,PHP,Java,C,C++,...

Wer das nicht will muß es nicht, that's it, that's Apple!

Wie gesagt, für mich war es mit einer der Gründe zu wechseln:
- echtes Unix (somit ein gewisses "ich bin zuhause" gefühl)
- schöne GUI
- gute Hardwareintegration (nix mit Kernel patchen, neu compilen, verschiedene Module ausprobieren wie unter Linux)

exakt das waren auch meine Gründe! Aber das gilt eben noch immer für die von Linux migrierte Minderheit!


BTW: Wir sind jetzt alle ziemlich OT hier, bitte kommt zum Thema zurück

 

[Kryptaesthesie]

beim Compilieren: stdio.h: No such file or directory

Hallo.
Um ein klein wenig zum Thema zurück zu kommen, hier mal eine Frage von mir:
ich habe folgende main.m:

// erstes Programm
#import <stdio.h>

int main (int argc, const char *argv[])
{
  printf ("Programming is fun.\n");
  
  return 0;
}

Kompilieren wollte ich es mit:
gcc main.m -o first.x -l objc
Das brachte aber folgenden Fehler hervor:
main.m:2:18: stdio.h: No such file or directory

Und genau ab dem Zeitpunkt bin ich überfragt...
Also ich denke mal, gcc weiß halt nicht, wo die stdio.h zu finden ist, die ich importiere.
Wie kann ich das Problem lösen?

Danke schon mal!
MfG Gerrit