MaWin schrieb:> Naja.> Geht besser, aber eher so mittel "gefährlich".
Ja, man hat ja noch ein Backup und git, aber trotzdem, so etwas dürfte
heutzutage doch nicht mehr bei einem Compiler möglich sein.
Ach ja:
1
clang --version
2
Debian clang version 11.0.1-2
3
Target: x86_64-pc-linux-gnu
4
Thread model: posix
5
InstalledDir: /usr/bin
Vielleicht trifft das bei neureren clang Versionen nicht mehr auf. Das
weiß ich leider nicht. Habe hier nur Debian stable im Einsatz.
bestellt - gelierfert schrieb:> clang13 macht's auch (und zwar genau das, was verlangt wurde -> einfach> super, wie bei C).
Wo steht im C Standard drin, dass der Compiler nicht überprüfen soll, ob
er die Quelldatei überschreibt?
Oder wo steht im C Standard drin, dass der Compiler die Quellcodedatei
"optimieren" soll?
Nano schrieb:> Habe mal spaßeshalber folgendes getestet:
Offenkundig unter Linux.
Das kann so schicke Dinge wie 2 Namen für eine Datei.
Was passiert bei hardlink out.put auf test rs
ln test.rs out.put
und dann deinen Befehlen
rustc test.rs -o out.put
etc ?
Ich wollte neulich etwas Java lernen und bin schon beim package-Name und
Verzeichnisstruktur gescheitert.
Anscheinend geht da mittlerweile ohne extra building tools gar nichts
mehr.
Es sei denn man studiert vorher wie man diese Verzeichnisstruktur per
Hand anlegt und was wo abgelegt werden soll. Einfach nur krank.
Nicht die Software führt die Befehle aus - du musst dich anpassen.
Nano schrieb:> so etwas dürfte heutzutage doch nicht mehr bei einem Compiler möglich> sein.
Warum zum Geier™ soll der Compiler für dich Mitdenken?
Spätestens, wenn du ein kaputtes Makefile (oder was auch immer dein
Buildsystem ist) gezimmert hast und dann eben sowas baust wie
1
cc -c foo.c
2
cc -o foo.c foo.o
könnte es der Compiler ohnehin nicht mehr direkt feststellen, das
Ergebnis ist das gleiche Fiasko, wie du es beim Clang halt direkt
bekommst. (Ähnliches habe ich selbst schon zur Genüge erlebt, eben, mit
besagten verkorksten Makefiles. Im Gegensatz dazu erscheint dein
Beispiel als eher künstlich produzierter pathologischer Fall.)
Wohl dem, der wenigstens ein VCS hat. ;-)
Jörg W. schrieb:> Nano schrieb:>> so etwas dürfte heutzutage doch nicht mehr bei einem Compiler möglich>> sein.>> Warum zum Geier™ soll der Compiler für dich Mitdenken?
Weil ein Computer dem Menschen Arbeit abnehmen und menschliche Fehler
vermeiden helfen soll.
Und weil es keinen einzigen triftigen Grund gibt, warum der Compiler so
etwas nicht prüfen sollte.
Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr
schnell im Compiler implementiert ist.
> Spätestens, wenn du ein kaputtes Makefile (oder was auch immer dein> Buildsystem ist) gezimmert hast und dann eben sowas baust wie> cc -c foo.c> cc -o foo.c foo.o>> könnte es der Compiler ohnehin nicht mehr direkt feststellen, das> Ergebnis ist das gleiche Fiasko, wie du es beim Clang halt direkt> bekommst. (Ähnliches habe ich selbst schon zur Genüge erlebt, eben, mit> besagten verkorksten Makefiles.
Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output
File auf *.c oder *.cpp endet. Es ist eine weltweit verbreitete
Konvention, dass C oder C++ Quellcode auf die Dateinamenserweiterung *.c
bzw. *.cpp und in seltenen Fällen auf *.cc, *.c++ oder *.cxx endet.
Fürs grobe reicht das vollkommen und der Build bleibt trotzdem
performant genug.
Alternativ könnte man auch die ersten drei Zeilen parsen.
Der meiste C und C++ Code beginnt mit einer #include Anweisung oder
einem Kommentar, gefolgt von einer #include Anweisung.
> Im Gegensatz dazu erscheint dein> Beispiel als eher künstlich produzierter pathologischer Fall.)
Dank TAB Taste ist der auf gescheiten Betriebssystemen ganz einfach zu
realisieren:
clang te<TAB> -o te<TAB><ENTER>
Das führt bei gegebener test.c Datei zu
clang test.c -o test.c
Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode
geschehen.
Nano schrieb:> Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr> schnell im Compiler implementiert ist.
Warum baust Du es dann nicht schnell ein und schickst den Entwicklern
ein diff, statt hier den nächsten Nano-Schwafelthread der Sorte "Ich
hätte das viel besser gemacht!" aufzumachen?
Nano schrieb:> Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode> geschehen.
Wie oft ist Dir das bisher passiert?
Hmmm schrieb:> Nano schrieb:>> Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr>> schnell im Compiler implementiert ist.>> Warum baust Du es dann nicht schnell ein und schickst den Entwicklern> ein diff,
Ganz einfach, hast du dir schonmal den Rattenschwanz an
Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und
clang gehostet wird, einen Account erstellen und bei einem Open Source
Projekt mitmachen kannst?
https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
Also ich habe darauf keinen Bock. Deswegen kriegen von mir github (und
gitlab Projekte, da ist es genauso schlimm) auch keine Bugreports mehr
von mir.
> statt hier den nächsten Nano-Schwafelthread der Sorte "Ich> hätte das viel besser gemacht!" aufzumachen?
Hmmm, du nimmst dich mal wieder zu wichtig. Du musst meine Threads ja
nicht lesen.
> Nano schrieb:>> Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode>> geschehen.>> Wie oft ist Dir das bisher passiert?
Du willst doch nicht Schwafeln, wozu fragst du also?
Warum macht man das so kompliziert?
Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann
nehme ich einfach make:
# make xxx
cc xxx.c -o xxx
Keine Tab-Taste, kein -o usw
Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.
Nano schrieb:> Ganz einfach, hast du dir schonmal den RattenschwanzNano schrieb:> Ganz einfach, hast du dir schonmal den Rattenschwanz an> Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und> clang gehostet wird, einen Account erstellen und bei einem Open Source> Projekt mitmachen kannst?
Über GitHub nehmen sie Patches gar nicht an, was ist deine nächste
Ausrede?
Nano schrieb:> clang test.c -o test.c> # PENG!!!
Das ist höchstens so gefährlich wie bspw.
1
irgendein_kommando >test.c
Das mit Clang ist mir noch nie passiert (dir offensichtlich auch nicht),
die ungewollte Umleitung von stdout in eine bereits existierende Datei
hingegen schon.
Nano schrieb:> Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output> File auf *.c oder *.cpp endet. Es ist eine weltweit verbreitete> Konvention, dass C oder C++ Quellcode auf die Dateinamenserweiterung *.c> bzw. *.cpp und in seltenen Fällen auf *.cc, *.c++ oder *.cxx endet.
Dann kommt der Nächste und schreibt
> Das mit Clang ist mir noch nie passiert (dir offensichtlich auch nicht),> die ungewollte Umleitung von stdout in eine bereits existierende Datei> hingegen schon.
Falls es die ›bash‹ ist, da hätten wir noch ›noclobber‹ im Angebot. ;-)
Ich finde das ehrlich gesagt auch bedenklich, dass der Compiler
Kommentare auf der Kommandozeile ausgibt (#PENG). Es gibt drei
vernünftige Kanäle stdout, stdwarn, stderr. #PENG ist peinlich, zumal
nicht alle Kommandozeilen eine bash sind.
Nano schrieb:> Weil ein Computer dem Menschen Arbeit abnehmen und menschliche Fehler> vermeiden helfen soll.> Und weil es keinen einzigen triftigen Grund gibt, warum der Compiler so> etwas nicht prüfen sollte.
Es gibt noch Millionen andere Fälle, mit denen man sich Daten
zerschießen kann. Du hast jetzt wahlfrei einen davon rausgepickt. Will
man die alle abfangen, bestehen die Programme irgendwann zu 95% aus
solchen Überprüfungen.
> Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output> File auf *.c oder *.cpp endet.
Wie du dein Output-File nennst, bleibt dir überlassen. Ich find's nicht
gut, in der Software zu viele Dinge zu verbieten, von denen der
Entwickler denkt, dass man sie nicht bräuchte. Das hat bei mir schon
öfter zu Frust geführt, wenn ich genau das dann eben doch mal gebraucht
habe.
> Es ist eine weltweit verbreitete Konvention, dass C oder C++ Quellcode> auf die Dateinamenserweiterung *.c bzw. *.cpp und in seltenen Fällen auf> *.cc, *.c++ oder *.cxx endet.
Es gibt noch andere gebräuchliche Endungen. Bei gcc z.B.:
1
file.cc
2
file.cp
3
file.cxx
4
file.cpp
5
file.CPP
6
file.c++
7
file.C
8
C++ source code that must be preprocessed.
>> Im Gegensatz dazu erscheint dein>> Beispiel als eher künstlich produzierter pathologischer Fall.)>> Dank TAB Taste ist der auf gescheiten Betriebssystemen ganz einfach zu> realisieren:
Mir ist das noch nie passert. Allerdings rufe ich den Compiler höchstens
mal für eine kleines Testprogramm von Hand auf. Bei allem anderen nutze
ich CMake und Konsorten.
Walter T. schrieb:> Ich finde das ehrlich gesagt auch bedenklich, dass der Compiler> Kommentare auf der Kommandozeile ausgibt (#PENG). Es gibt drei> vernünftige Kanäle stdout, stdwarn, stderr. #PENG ist peinlich, zumal> nicht alle Kommandozeilen eine bash sind.
Kennst du nicht stdpeng?
Wurde damals zusammen mit stdwarn eingeführt.
Nano schrieb:> Mehr muss ich dazu nicht sagen, oder?
„Das grösste Problem von Leuten, die versuchen, etwas absolut
idiotensicherers zu konstruieren, ist, dass sie den Einfallsreichtum von
absoluten Idioten unterschätzen.“
Douglas Adams
Norbert schrieb:> Falls es die ›bash‹ ist, da hätten wir noch ›noclobber‹ im Angebot. ;-)
Ja, ich weiß. Ich wollte nur aufzeigen, dass es außer der Verwendung von
Clang noch andere Möglichkeiten gibt, Dateien zu überschreiben, die
weniger an den Haaren herbeigezogen sind. Ich selber verwende noclobber
nicht, aber für Nano, bei dem alles ganz idiotensicher sein muss, ist
das sicher eine gute Option. Noch besser wäre es, wenn man irgendwie >|
verbieten könnte, das ja noclobber überreitet und damit gefährlich ist
;-)
MaWin schrieb:> Was passiert bei hardlink out.put auf test rs>> ln test.rs out.put>> und dann deinen Befehlen>> rustc test.rs -o out.put>> etc ?
Den Fall kann man einfach abfangen indem man die Überprüfung mit der
eindeutigen File-ID (Widows) macht, wie es ordentliche Programmierer
eben so machen.
Ich bin mir nicht sicher, glaube aber das make den Fall auch erkennt,
wenn in jeder Regel nur ein Befehl drinnen ist.
Der Vollständigkeit halber: der MS cl macht es wie clang.
Damit hatte ich aber noch nie Probleme.
Was mir aber schon mal passiert ist:
rm -rf /$(EMPTY_VARIABLE)
Zum Glück war das noch zu Zeiten, wo Festplatten langsam waren.
Aber richtig schlimm ist der Widows File Explorer:
File Markieren -> Rechte Maustaste -> "Umbenennen" ist gleich neben
"Löschen". Dafür vergebe ich 10 Liegestütz...
udok schrieb:> Den Fall kann man einfach abfangen indem man die Überprüfung mit der> eindeutigen File-ID (Widows) macht
Unter unix Systemen vergleicht man normalerweise device (st_dev) & inode
(st_ino) Nummer mit stat(2). Device Nummer kann man nehmen, um zu
checken, ob es auf dem selben Filesystem / Mountpoint ist, und jenachdem
auch, von welchem Device es kommt usw. Die Inode Nummer ist sollte bei
jeder Datei des selben device anders sein.
stat(2): https://linux.die.net/man/2/stat
Mimimimi.
Urdeutsche Versicherungsmentalität.
Echte Cowboys tragen ihre Freunde (Smith & Wesson) bevorzugt entsichert.
Und dann noch den Bug-Report verweigern. Ts ts ts...
udok schrieb:> Den Fall kann man einfach abfangen
Natürlich, den mit gleichlautenden Filenamen auch, die Frage ist nur, ob
es so gemacht wurde oder gar
source/test.c
als anders angesehen wird als
source/library/../zest.c
Sein Schweigen spricht Bände.
udok schrieb:> Aber richtig schlimm ist der Widows File Explorer:> File Markieren -> Rechte Maustaste -> "Umbenennen" ist gleich neben> "Löschen". Dafür vergebe ich 10 Liegestütz...
Oh ja, das finde ich auch.
Zum Glück ist's meist nicht irreversibel, man kann ja Ding auch wieder
aus der Mülltonne holen.
Seit ich mir angewöhnt habe, Umbenennungen mit nur noch mit F2 zu
initiieren, passiert mir das nicht nur nicht mehr und der Sollvorgang
geht deutlich schneller. ;)
> It is not UNIX’s job to stop you from shooting your foot. If you so> choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr. Foot> in the most efficient way it knows.
– Terry Lambert
PittyJ schrieb:> Warum macht man das so kompliziert?>> Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann> nehme ich einfach make:> # make xxx> cc xxx.c -o xxx>> Keine Tab-Taste, kein -o usw> Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.
Wenn ich nur mal schnell was testen will, dann mach ich dafür keine IDE
auf und lege dort auch kein neues Projekt an, sondern ich nehme einen
Editor und schreib die eine kurze Quellcodedatei damit und wenn ich
dann damit fertig bin und das testen will, dann erstelle ich dafür auch
nicht erst eine Makefile, denn es ist ja nur ein einzige Datei.
Deswegen gebe ich den Compilerbefehl in der Kommandozeile ein und nutze
die Tab Taste und dann pass ich halt auf, dass ich die Outputdatei
entsprechend anpasse. Überschrieben wurde bei mir noch nichts, das
könnte aber auch daran liegen, dass ich bisher immer gcc für so etwas
benutzt habe und der hilft diesen Fehler zu vermeiden, siehe oben.
Und sobald der Befehl in einer Konsole mal abgeschickt wurde, kann man
ihn durch die History und Cursortasten ganz leicht wieder abrufen.
Insofern ist ein Makefile da gar nicht nötig.
Aber natürlich nutze ich Makefiles bei richtigen Projekten, die bestehen
aber auch nicht nur aus einer Quellcodedatei, sondern mehreren. Da macht
der extra Aufwand für die Makefile bzw. Projektdatei in der IDE dann
auch Sinn.
Jemand schrieb:> Nano schrieb:>> Ganz einfach, hast du dir schonmal den Rattenschwanz> Nano schrieb:>> Ganz einfach, hast du dir schonmal den Rattenschwanz an>> Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und>> clang gehostet wird, einen Account erstellen und bei einem Open Source>> Projekt mitmachen kannst?>> Über GitHub nehmen sie Patches gar nicht an, was ist deine nächste> Ausrede?
Es kann natürlich sein, dass jedes Projekt das anders handhabt. Und so
genau guck ich mir die auf GitHub und GitLab gehosteten Projekte dann
auch nicht an.
Fest steht aber, dass der Bugreport darüber läuft und da fängt es schon
an.
Denn wenn man einen Patch einreicht, dann macht es Sinn, dass dafür
bereits ein Bugreport existiert. Denn dann kann man schön schreiben
"Here's a patch, this solves Bug #58237305".
Das erhöht die Wahrscheinlichkeit dass er gleich angenommen wird und in
der Versionshistorie ist der Commit dann auch schön strukturiert
hinterlegt, falls sich mal jemand fragen sollte, warum damals dieser
Code dazu kam.
In Maillinglisten geht so etwas ja eher unter.
Nano schrieb:> Wo steht im C Standard drin, dass der Compiler nicht überprüfen soll, ob> er die Quelldatei überschreibt?
Und was hat das mit dem C-Standard zu tun? Nichts.
Ich musste noch nie Code aus einer anderen Datei oder Ausgabe in eine
Quellcodedatei schieben.
Ich mach das beim Überprüfen von Prüfsummen oder wenn ich die Dateien in
einem Ordner mit zusätzlichen Informationen beschriften will und die
Dateinamen dann in einer Textdatei brauche, in der ich die Informationen
hinterlege, dann nutze ich aber immer den >> Operator.
Beispiel:
ls >> files.bbs
nano files.bbs
> Das mit Clang ist mir noch nie passiert (dir offensichtlich auch nicht),
Ja, ich habe bisher auch immer gcc benutzt.
> die ungewollte Umleitung von stdout in eine bereits existierende Datei> hingegen schon.
Ja, könnte vorkommen, aber in meinem Fall ist es eher unwahrscheinlich,
dass es in eine Quellcodedatei umgeleitet wird.
> Dann kommt der Nächste und schreibt>>
1
> clang test.c -o test.h
2
>
Das ist eher unwahrscheinlich, denn da ist ja ein zu tun erforderlich,
also dass er nach dem Tab das c entfernt und ein h hinmacht.
Wenn er aber weiß, dass er eine Executable erstellen will, hängt er da
eher bin, run oder exe dran oder macht es mitsamt . ganz weg.
> oder auch>>
1
> clang test.c -o wichtiges_dokument.docx
2
>
Das passiert höchstens Leuten, die keine Verzeichnisse benutzen und
alles unstrukuriert im ~/ Ordner liegen haben.
Nano schrieb:> PittyJ schrieb:>> Warum macht man das so kompliziert?>>>> Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann>> nehme ich einfach make:>> # make xxx>> cc xxx.c -o xxx>>>> Keine Tab-Taste, kein -o usw>> Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.>> Wenn ich nur mal schnell was testen will, dann mach ich dafür keine IDE> auf und lege dort auch kein neues Projekt an, sondern ich nehme einen> Editor und schreib die eine kurze Quellcodedatei damit und wenn ich> dann damit fertig bin und das testen will, dann erstelle ich dafür auch> nicht erst eine Makefile, denn es ist ja nur ein einzige Datei.
...
> Aber natürlich nutze ich Makefiles bei richtigen Projekten, die bestehen> aber auch nicht nur aus einer Quellcodedatei, sondern mehreren. Da macht> der extra Aufwand für die Makefile bzw. Projektdatei in der IDE dann> auch Sinn.
Du weißt aber schon, dass man, wenn man die default-rules von make
verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten
makefile auskommt, oder? Keine IDE notwendig.
Rolf M. schrieb:> Nano schrieb:>> Weil ein Computer dem Menschen Arbeit abnehmen und menschliche Fehler>> vermeiden helfen soll.>> Und weil es keinen einzigen triftigen Grund gibt, warum der Compiler so>> etwas nicht prüfen sollte.>> Es gibt noch Millionen andere Fälle, mit denen man sich Daten> zerschießen kann. Du hast jetzt wahlfrei einen davon rausgepickt. Will> man die alle abfangen, bestehen die Programme irgendwann zu 95% aus> solchen Überprüfungen.
Es hat schon seinen Grund, warum gcc, g++ und der Rust Compiler darauf
achten.
Also ist das eben nicht ein Spezialfall, sondern halt schon etwas, was
bei Nutzern vorkommt und somit problematisch sein kann.
Wäre doch mal interessant zu erfahren, wie es die Compiler von Intel,
Microsoft und Co. machen.
Beim OpenWatcom Compiler habe ich es gerade unter FreeDOS überprüft.
Da überschreibt das wcl.exe das Compile and Link Utility die
Quellcodedatei, wenn man diese mit -fe=DATEINAME also output Datei
angibt.
Beim Compiler wcc.exe, der allerdings nur Objektcode erzeugt und das
ganze noch nicht verlinkt, ist es genauso, wenn man mit -fo=DATEINAME
angibt.
Unter FreeDOS ist das ganze aber dann doch sehr theoretisch, da man wcl
auch einfach ohne output Datei starten kann und der Watcom Compiler
automatisch die Quellcodedatei ohne Dateiendung als Namen für die
Executable nimmt und noch ein .EXE dranhängt.
Beim Microsoft Compiler dürfte das ähnlich sein, denn unter Windows
bekommen die Ausführbaren Dateien alle eine eigene Dateiendung. Im
Normalfall also *.EXE.
Wirklich betroffen sind somit nur Unix und Linux Systeme, wo ein
Programm jede beliebige Dateiendung annehmen kann.
Bei MacOS X weiß ich es nicht.
>> Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output>> File auf *.c oder *.cpp endet.>> Wie du dein Output-File nennst, bleibt dir überlassen. Ich find's nicht> gut, in der Software zu viele Dinge zu verbieten, von denen der> Entwickler denkt, dass man sie nicht bräuchte.
In dem Fall ist es aber eindeutig.
Wenn man eine ausführbare Datei will, dann wird man die nicht *.c oder
*.cpp nennen.
>> Es ist eine weltweit verbreitete Konvention, dass C oder C++ Quellcode>> auf die Dateinamenserweiterung *.c bzw. *.cpp und in seltenen Fällen auf>> *.cc, *.c++ oder *.cxx endet.>> Es gibt noch andere gebräuchliche Endungen. Bei gcc z.B.:>
1
> file.cc
2
> file.cp
3
> file.cxx
4
> file.cpp
5
> file.CPP
6
> file.c++
7
> file.C
8
> C++ source code that must be preprocessed.
9
>
Da ist eigentlich nur noch cp dabei.
Die anderen habe ich schon aufgeführt und unterscheiden sich bestenfalls
noch in der Groß- und Kleinschreibung.
>>> Im Gegensatz dazu erscheint dein>>> Beispiel als eher künstlich produzierter pathologischer Fall.)>>>> Dank TAB Taste ist der auf gescheiten Betriebssystemen ganz einfach zu>> realisieren:>> Mir ist das noch nie passert. Allerdings rufe ich den Compiler höchstens> mal für eine kleines Testprogramm von Hand auf. Bei allem anderen nutze> ich CMake und Konsorten.
Ich doch auch, aber ich mache von TAB ausgiebig Gebrauch wenn ich das
von Hand mache.
Im Normalfall ändere ich somit immer die Dateiendung von Hand, da TAB
immer in *.c endet, falls noch keine andere Datei, als die
Quellcodedatei im Ordner vorhanden ist.
GCC schützt hier dann halt, clang würde es nicht tun.
Yalu X. schrieb:> Norbert schrieb:>> Falls es die ›bash‹ ist, da hätten wir noch ›noclobber‹ im Angebot. ;-)>> Ja, ich weiß. Ich wollte nur aufzeigen, dass es außer der Verwendung von> Clang noch andere Möglichkeiten gibt, Dateien zu überschreiben, die> weniger an den Haaren herbeigezogen sind.
Das Tabben ist ganz gewiss nicht an den Haaren herbeigezogen.
Die meisten Leute werden sich halt darauf einstellen und wenn sie den
Fehler mal gemacht haben sollten, besser darauf acht geben. Die größte
Gefahr liegt also darin, es mal Ausversehen zu machen, weil man
ungewollt an die ENTER Taste rankommt, während man eigentlich Backspace
drücken wollte um die Dateiendung anzupassen.
Insofern ist das ein reales Szenario dass es passieren kann und da gcc,
g++ und rustc das abfängt kann man stark davon ausgehen, dass es auch
vorkommt.
Nano schrieb:> Das ist eher unwahrscheinlich, denn da ist ja ein zu tun erforderlich,> also dass er nach dem Tab das c entfernt und ein h hinmacht.
Also geht für dich die Gefahr nicht von Clang aus, sondern von der
Tab-Completion. Diese kannst du deaktivieren, um der Gefahr aus dem Weg
zu gehen. Damit ist nicht nur das von dir beschriebene "Problem" mit
Clang beseitigt, sondern gleich auch alle anderen Probleme, die durch
unkontrolliertes Tabben enstehen können, so bspw. beim Kommando
1
rm test<tab>
mit dem du eigentlich test.bin löschen möchtest. Wenn test.bin aber noch
nicht oder nicht mehr existiert, wird der Dateiname zu test.c ergänzt,
und weg ist deine Quelldatei. Ohne Tab-Completion wird dies nicht
passieren.
udok schrieb:> Der Vollständigkeit halber: der MS cl macht es wie clang.> Damit hatte ich aber noch nie Probleme.
Danke das ist gut zu wissen.
> Aber richtig schlimm ist der Widows File Explorer:> File Markieren -> Rechte Maustaste -> "Umbenennen" ist gleich neben> "Löschen". Dafür vergebe ich 10 Liegestütz...
Unter Windows hast du ja den Papierkorb. Das sollte jetzt kein Problem
sein.
Wenn es Dir doch nur um das Testen eines kleinen Beispiels geht (und Du
ja auch sagst, dass Du Verzeichnisse benutzt ;-) Yeah!), dann schreib
doch einfach:
1
clangsrc1.ccsrc2.c
Dann sparst Du Dir Tipp-Arbeit und der potentielle Fehler kann auch
nicht auftreten.
Das Ganze hier erscheint mir extrem konstruiert...
Wilhelm M. schrieb:> Du weißt aber schon, dass man, wenn man die default-rules von make> verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten> makefile auskommt, oder? Keine IDE notwendig.
Natürlich weiß ich das, aber nochmal, warum soll ich für eine einzige
Quellcodedatei eine Makefile anlegen?
Du weißt doch hoffentlich schon, dass Makefiles in der Regel dazu da
sind, zu verhindern, das Code, der bereits compiliert und als Objektcode
vorliegt nicht noch einmal zu compilieren, wenn er nicht verändert
wurde.
Makefile haben somit bei nur einer Datei keinen Nutzen, ihr Nutzen
ergibt sich erst bei mehreren Quellcodedateien.
Nano schrieb:> Wilhelm M. schrieb:>> Du weißt aber schon, dass man, wenn man die default-rules von make>> verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten>> makefile auskommt, oder? Keine IDE notwendig.>> Natürlich weiß ich das, aber nochmal, warum soll ich für eine einzige> Quellcodedatei eine Makefile anlegen?
Du hast es mal wieder nicht gelesen oder nix verstanden: OHNE makefile!
Yalu X. schrieb:> Nano schrieb:>> Das ist eher unwahrscheinlich, denn da ist ja ein zu tun erforderlich,>> also dass er nach dem Tab das c entfernt und ein h hinmacht.>> Also geht für dich die Gefahr nicht von Clang aus, sondern von der> Tab-Completion. Diese kannst du deaktivieren, um der Gefahr aus dem Weg> zu gehen.
Die Gefahr ist die Kombination aus beidem und natürlich werde ich die
Tab Completion nicht deaktivieren, wenn sie einen wesentlichen Nutzen
hat. Also dummer Vorschlag.
Damit ist nicht nur das von dir beschriebene "Problem" mit
> Clang beseitigt, sondern gleich auch alle anderen Probleme, die durch> unkontrolliertes Tabben enstehen können, so bspw. beim Kommando>>
1
> rm test<tab>
2
>
>> mit dem du eigentlich test.bin löschen möchtest. Wenn test.bin aber noch> nicht oder nicht mehr existiert, wird der Dateiname zu test.c ergänzt,> und weg ist deine Quelldatei. Ohne Tab-Completion wird dies nicht> passieren.
Ich lösche aber nicht mit
Wilhelm M. schrieb:> Wenn es Dir doch nur um das Testen eines kleinen Beispiels geht (und Du> ja auch sagst, dass Du Verzeichnisse benutzt ;-) Yeah!), dann schreib> doch einfach:>>
1
>clangsrc1.ccsrc2.c
2
>
>> Dann sparst Du Dir Tipp-Arbeit und der potentielle Fehler kann auch> nicht auftreten.>> Das Ganze hier erscheint mir extrem konstruiert...
Es kommt bei mir auch mal vor, dass ich zum Vergleich noch eine weitere
Testdatei schreibe.
a.out als Outpuddatei ist daher nicht die Lösung. Ich nutze immer -o um
die Outputdatei festzulegen.
Nano schrieb:> Wilhelm M. schrieb:>> Wenn es Dir doch nur um das Testen eines kleinen Beispiels geht (und Du>> ja auch sagst, dass Du Verzeichnisse benutzt ;-) Yeah!), dann schreib>> doch einfach:>>>>
1
>>clangsrc1.ccsrc2.c
2
>>
>>>> Dann sparst Du Dir Tipp-Arbeit und der potentielle Fehler kann auch>> nicht auftreten.>>>> Das Ganze hier erscheint mir extrem konstruiert...>> Es kommt bei mir auch mal vor, dass ich zum Vergleich noch eine weitere> Testdatei schreibe.
Dann würde ich vom Workflow eher die vorige a.out an diese Seite moven
...
> a.out als Outpuddatei ist daher nicht die Lösung. Ich nutze immer -o um> die Outputdatei festzulegen.
Na, wenn Du das immer nutzt, dann ist ja hier jeglicher Kommentar
nutzlos ;-)
Wilhelm M. schrieb:> Nano schrieb:>> Wilhelm M. schrieb:>>> Du weißt aber schon, dass man, wenn man die default-rules von make>>> verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten>>> makefile auskommt, oder? Keine IDE notwendig.>>>> Natürlich weiß ich das, aber nochmal, warum soll ich für eine einzige>> Quellcodedatei eine Makefile anlegen?>> Du hast es mal wieder nicht gelesen oder nix verstanden: OHNE makefile!
Ah, jetzt verstehe ich dich.
Das überschreibt dir dann den Quellcode.
1
$ ls
2
test.c
3
$ make
4
gcc -c test.c
5
gcc -o test.c test.o
6
$ ls
7
test.c test.o
8
$ file test.c
9
test.c: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f4ce5c42d61f5fcdbeb9da51cf23d1029b11bfcf, for GNU/Linux 3.2.0, not stripped
Also keinesfalls besser, sondern erst Recht ein Grund dem Compiler
beizubringen, dass er Quellcodedateien nicht überschreiben soll.
Denn so ist das sogar bei gcc möglich, einfach in dem man das Makefile
nicht anlegt und make angibt.
Wilhelm M. schrieb:>> a.out als Outpuddatei ist daher nicht die Lösung. Ich nutze immer -o um>> die Outputdatei festzulegen.>> Na, wenn Du das immer nutzt, dann ist ja hier jeglicher Kommentar> nutzlos ;-)
???
Wilhelm M. schrieb:> Nano schrieb:>> Das überschreibt dir dann den Quellcode.>> Kann nicht sein, da hast Du wohl noch ein altes makefile rumliegen:> $ make abc> g++ abc.cc -o abc
Oh ja, stimmt. Mein Fehler.
Das war noch wegen Jörgs Einwand #7084421 ganz oben.
Dennoch ist das für mich kein Lösung, da man so *.bin Dateien nicht
bequem per
rm *.bin
löschen kann, sondern so jetzt explizit immer angeben müsste, was
gelöscht werden soll.
Jetzt weißt du vielleicht auch, warum ich -o immer benutze und meine
Executable selbst benenne, einschließlich der Dateiendung.
Weglassen würde ich die höchstens für einen Release der fertigen
Software.
Nano schrieb:> Dennoch ist das für mich kein Lösung, da man so *.bin Dateien nicht> bequem per> rm *.bin> löschen kann, sondern so jetzt explizit immer angeben müsste, was> gelöscht werden soll.
Naja, wenn Du alle bisher präsentierten Lösungsvorschläge ablehnst, ist
wirklich nicht viel zu machen.
Nano schrieb:> Jetzt weißt du vielleicht auch, warum ich -o immer benutze und meine> Executable selbst benenne, einschließlich der Dateiendung.
Nee, erschließt sich mir überhaupt nicht.
Nano schrieb:> Oh ja, stimmt. Mein Fehler.> Das war noch wegen Jörgs Einwand #7084421 ganz oben.
Wer sich mit make auskennt (Deine Aussage oben), dem sollte das doch
klar sein, dass das nicht sein kann.
Nano schrieb:> PittyJ schrieb:>> Warum macht man das so kompliziert?>>>> Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann>> nehme ich einfach make:>> # make xxx>> cc xxx.c -o xxx>>>> Keine Tab-Taste, kein -o usw>> Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.>> Wenn ich nur mal schnell was testen will, dann mach ich dafür keine IDE> auf und lege dort auch kein neues Projekt an, sondern ich nehme einen> Editor und schreib die eine kurze Quellcodedatei damit und wenn ich> dann damit fertig bin und das testen will, dann erstelle ich dafür auch> nicht erst eine Makefile, denn es ist ja nur ein einzige Datei.> Deswegen gebe ich den Compilerbefehl in der Kommandozeile ein und nutze> die Tab Taste und dann pass ich halt auf, dass ich die Outputdatei> entsprechend anpasse. Überschrieben wurde bei mir noch nichts, das> könnte aber auch daran liegen, dass ich bisher immer gcc für so etwas> benutzt habe und der hilft diesen Fehler zu vermeiden, siehe oben.>
Hatte ich auch nicht. Kein Makefile, keine extra Regeln.
Ich hatte nur xxx.c angelegt, und auf der Kommandozeile 'make'
eingegben.
Das war alles.
Wilhelm M. schrieb:> Nano schrieb:>> Jetzt weißt du vielleicht auch, warum ich -o immer benutze und meine>> Executable selbst benenne, einschließlich der Dateiendung.>> Nee, erschließt sich mir überhaupt nicht.
Na weil ich dann alle Executables im Ordner mit einem einfachen
rm *.bin
wegräumen kann, ohne jede Datei einzeln eingeben zu müssen.
Ein einfaches
rm *
würde nämlich auch die Quellcodedateien löschen, was ja nicht immer
gewünscht ist.
Deswegen kriegen Executables bei mir unter Linux immer die Dateiendung
*.bin
Wilhelm M. schrieb:> Nano schrieb:>> Oh ja, stimmt. Mein Fehler.>> Das war noch wegen Jörgs Einwand #7084421 ganz oben.>> Wer sich mit make auskennt (Deine Aussage oben), dem sollte das doch> klar sein, dass das nicht sein kann.
Ich nutze make immer mit Makefile, nicht ohne. Und wenn doch, dann weil
ich es vergessen habe, dann hänge ich da aber keine Quelldatei als
Parameter hinten dran.
Und make ohne Target und ohne Makefile liefert die bekannte Meldung,
dass es ohne Target nicht weiter weiß.
make quellcodedatei
ist für mich höchst unüblich. Vor allem wenn man noch zu mit TAB zu
test.c Tabben würde und das .c noch wegmachen würde.
PittyJ schrieb:> Hatte ich auch nicht. Kein Makefile, keine extra Regeln.> Ich hatte nur xxx.c angelegt, und auf der Kommandozeile 'make'> eingegben.> Das war alles.
Das führt zu
1
make
2
make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden. Schluss.
Nano schrieb:> Wilhelm M. schrieb:>> Nano schrieb:>>> Oh ja, stimmt. Mein Fehler.>>> Das war noch wegen Jörgs Einwand #7084421 ganz oben.>>>> Wer sich mit make auskennt (Deine Aussage oben), dem sollte das doch>> klar sein, dass das nicht sein kann.>> Ich nutze make immer mit Makefile, nicht ohne. Und wenn doch, dann weil> ich es vergessen habe, dann hänge ich da aber keine Quelldatei als> Parameter hinten dran.
Ist auch nicht die Quell-Datei: Deine Lesekompetenz lässt echt zu
wünschen übrig.
Schau nochmal in meinem Beitrag:
Beitrag "Re: Gefährlicher Compiler"> Und make ohne Target und ohne Makefile liefert die bekannte Meldung,> dass es ohne Target nicht weiter weiß.>> make quellcodedatei> ist für mich höchst unüblich.
Und ist in diesem Fall auch falsch (s.o.)
Wie war das: Du kennst Dich mit make aus?
Nano schrieb:> Na weil ich dann alle Executables im Ordner mit einem einfachen> rm *.bin> wegräumen kann, ohne jede Datei einzeln eingeben zu müssen.
Kannst Du auch dem make überlassen.
Nano schrieb:> Und seit wann gibt es clang? Sind doch jetzt schon sicher ein paar> Jahre.
Er hat noch bisschen Zeit dafür. Seit wann gibt es GCC? Wikipedia sagt,
seit 1987.
Seit wann gibt es das von dir gewünschte Feature?
Seit 2014:
1
commit 3d00119cfbbcadccb56e5a0b8fe447ad7554d681
2
Author: Anthony Brandon <anthony.brandon@gmail.com>
3
Date: Tue Nov 11 23:33:25 2014 +0000
4
5
re PR driver/36312 (should refuse to overwrite input file with output file)
6
7
…
8
gcc/ChangeLog:
9
10
2014-11-11 Anthony Brandon <anthony.brandon@gmail.com>
11
Manuel López-Ibáñez <manu@gcc.gnu.org>
12
13
PR driver/36312
14
* diagnostic-core.h: Add prototype for fatal_error.
15
* diagnostic.c (fatal_error): New function fatal_error.
16
* gcc.c (store_arg): Remove have_o_argbuf_index.
17
(process_command): Check if input and output files are the same.
18
* toplev.c (init_asm_output): Check if input and output files are
19
the same.
Wie du sehen kannst, war es übrigens ein Bugreport (PR = "problem
report"), der den Einbau des Tests bewirkt hat. Ergo, solange du (da
es dich ja stört) nichts tust, sind die Chancen gering, dass bei Clang
irgendwer was von sich aus unternimmt.
@Nano:
Du könntest auch einfach einen Wrapper in Form eines Shell-Skripts
schreiben, das die Kommandozeilenargumente vor dem eigentlichen Aufruf
von clang exakt nach deinen Vorstellungen prüft. Das sollte ja nicht
allzu schwer sein.
man man man... also wenn das deine täglichen Probleme sind die du hast
und lösen musst :D Hoffe du musst in deiner Software nie nach race
conditions suchen.
Aber das kann dir ja nicht passieren ;)
Wünsche allen ein erholsame Pfingsten, Bug-Reports gehen da am ringsten.
Yalu X. schrieb:> @Nano:> Du könntest auch einfach einen Wrapper in Form eines Shell-Skripts> schreiben, das die Kommandozeilenargumente vor dem eigentlichen Aufruf> von clang exakt nach deinen Vorstellungen prüft. Das sollte ja nicht> allzu schwer sein.
Das ist mir schon klar, es geht hier aber ums Prinzip. Das Problem
müsste bei clang gelöst werden.
Jörg W. schrieb:> Wie du sehen kannst, war es übrigens ein Bugreport (PR = "problem> report"), der den Einbau des Tests bewirkt hat. Ergo, solange du (da> es dich ja stört) nichts tust, sind die Chancen gering, dass bei Clang> irgendwer was von sich aus unternimmt.
Wie schon gesagt, solange man so viele Nutzungsbedingungen bei github
durchlesen muss, nur um einen Bugreport zu posten, sollten die clang
Maintainer erst einmal ein eigene Bugreportseite ohne diese Hürden
aufmachen, dann kann ich auch Bugs reporten.
Dann wirst du vermutlich auch noch nächstes und übernächstes Jahr auf
dieses Feature warten müssen. Kann ja nicht so wichtig sein, wenn dir
das Durchlesen von ein paar Richtlinien über die Einreichung von Bugs
und Patches bereits dermaßen zu viel ist.
Jörg W. schrieb:> wenn dir> das Durchlesen von ein paar Richtlinien über die Einreichung von Bugs> und Patches bereits dermaßen zu viel ist.
Bitte lies richtig, es geht nicht um Richtlinien wie man Bugs einreicht,
sondern um so Sachen, was die mit deinen Daten machen dürfen, ob sie die
an Drittfirmen weitergeben dürfen, ob du mit Werbung zugekleistert
werden darfst, ob du deine Rechte an all dem abgibst, was du uploadest
usw..
Sourceforge kriegt das mit wenigen Zeilen Text hin, bei github ist es
mehr wie bei Steam.
Und ja, es gibt Plattformen, die weniger invasiv sind. Gute Open Source
Projekte hosten selber.
Aber lass mich raten, als du dich bei github registriert hast, hast du
das ganze Zeug schlichtweg nicht gelesen und einfach unterschrieben.
Nano schrieb:> Aber lass mich raten, als du dich bei github registriert hast, hast du> das ganze Zeug schlichtweg nicht gelesen und einfach unterschrieben.
Für Menschen, die Probleme mit dem Lesen und Erfassen langer Texte
haben, gibt es jeweils noch eine Kurzfassung.
Zum Thema Urheberrecht heisst es z.B.:
> Short version: You own content you create, but you allow us certain> rights to it, so that we can display and share the content you post.> You still have control over your content, and responsibility for it,> and the rights you grant us are limited to those we need to provide> the service. We have the right to remove content or close Accounts> if we need to.
Aber Du wirst bestimmt noch weitere Ausreden finden, diesen "Bug" nicht
einfach zu beheben. Alles ausser "Ich kann es nicht", das würdest Du
niemals zugeben.
Du kannst ja hier gern weiter über das böse Github wehklagen.
An Clang wird sich daran allerdings kaum was ändern, und wegen deines
Wehklagens werden sie sicher auch nicht die Hosting-Plattform wechseln.
So what. Clone das Repository (dafür musst du dich nicht registrieren),
bau deine Änderung ein und hoste es selbst.
Witzigerweise bin ich bei Github bislang noch nie mit Werbung zugemüllt
worden, bei Sourceforge dagegen ständig.
Hmmm schrieb:> Alles ausser "Ich kann es nicht", das würdest Du> niemals zugeben.
So etwas wäre ja auch eine Lüge.
Warum sollte ich also lügen?
Und selbst wenn ich dir solche Lügen auftischen würde, würdest du mir
nicht glauben, weil es trivial ist, die Parameter von *argv[] zu
vergleichen.
Ups, habe ich dir jetzt verraten, wie man das Problem löst, weil du es
nicht wusstest?
Nano schrieb:> Jörg W. schrieb:>> wenn dir>> das Durchlesen von ein paar Richtlinien über die Einreichung von Bugs>> und Patches bereits dermaßen zu viel ist.>> Bitte lies richtig, es geht nicht um Richtlinien wie man Bugs einreicht,> sondern um so Sachen, was die mit deinen Daten machen dürfen, ob sie die> an Drittfirmen weitergeben dürfen, ob du mit Werbung zugekleistert> werden darfst, ob du deine Rechte an all dem abgibst, was du uploadest> usw..
Minimi, bla, bla bla
Mach nen fork des repos, bau Deine Traumlösung ein, fertig.
Das kannst Du dauerhaft so machen, viele Konflikte wird es beim merge /
rebase wohl nicht geben an der Stelle.
Und wenn Du ganz freundlich bist, erstelle eine Pull-Request. Oder sende
Deine Patch ganz einfach an die ML. Und wenn er gut gemacht ist, wird er
bestimmt angenommen werden. Oh, er muss nicht nur gut gemacht sein, auch
muss er sich an bestimmte Spielregeln halten. Bekommst Du das hin?
Wilhelm M. schrieb:> Mach nen fork des repos, bau Deine Traumlösung ein, fertig.
Mimimimi
Warum sollte ich das machen, dann müsste ich den Fork ja auch noch
pflegen und alle Änderungen erneut einpflegen.
Dummer Vorschlag von dir.
> Und wenn Du ganz freundlich bist, erstelle eine Pull-Request. Oder sende> Deine Patch ganz einfach an die ML. Und wenn er gut gemacht ist, wird er> bestimmt angenommen werden.
Ich finde es ja schon interessant, das du und Hmm wollen, dass ich
dieses Bug fixe. Könnte es vielleicht daran liegen dass euch dieser Bug
am meisten stört?
Ich selbst nutze ja gcc und bin daher nicht davon betroffen, schon
vergessen?
Und der Thread ist nur da, um diesen Missstand bei clang mal kurz
anzusprechen und ihr beiden macht jetzt ein Theather drauß.
Nano schrieb:> Wilhelm M. schrieb:>> Mach nen fork des repos, bau Deine Traumlösung ein, fertig.>> Mimimimi
Was ist daran Mimimi? Es war ein konkreter Vorschlag, kein Herumjammern,
wie Du es hier seit Anfang machst.
> Warum sollte ich das machen, dann müsste ich den Fork ja auch noch> pflegen und alle Änderungen erneut einpflegen.
Ein git rebase main ist Dir zuviel?
> Dummer Vorschlag von dir.
Nun, es ist immerhin ein konkreter Vorschlag. Davon hast Du noch nicht
soviel gebracht.
>> Und wenn Du ganz freundlich bist, erstelle eine Pull-Request. Oder sende>> Deine Patch ganz einfach an die ML. Und wenn er gut gemacht ist, wird er>> bestimmt angenommen werden.>> Ich finde es ja schon interessant, das du und Hmm wollen, dass ich> dieses Bug fixe. Könnte es vielleicht daran liegen dass euch dieser Bug> am meisten stört?
Mich stört er nicht, es ist mir noch nie passiert.
Ich kann im übrigen auch mit Tools wie make, cmake, qmake, ninja, ...
umgehen.
> Und der Thread ist nur da, um diesen Missstand bei clang mal kurz> anzusprechen und ihr beiden macht jetzt ein Theather drauß.
Der Thread ist dazu da:
Beitrag "Re: Gefährlicher Compiler"
Wilhelm M. schrieb:> Der Thread ist dazu da:>> Beitrag "Re: Gefährlicher Compiler"
Das ist wohl eher der Grund warum du hier so viele Nonsense-Kommentare
schreibst um den Thread künstlich in die Länge zu ziehen.
Nano schrieb:> ihr beiden macht jetzt ein Theather
Nö, das Theater hast du angefangen.
Alle anderen hier interessiert dein Bug einen (vom Moderator zensiert).
Wie du dem restlichen Thread unschwer entnehmen kannst, ist von allen
anderen Mitdiskutanten außer dir noch nie einer überhaupt darüber
gestolpert.
"Ansprechen" kannst du natürlich viel, aber davon ändert sich rein gar
nichts.
Jörg W. schrieb:> Nano schrieb:>> ihr beiden macht jetzt ein Theather>> Nö, das Theater hast du angefangen.
Nein, ich habe nur über einen Bug berichtet.
Diese ganze Fragerrei und in die Länge ziehen kam von den beiden oben
genannten und wie ich gerade sehe, auch von dir.
Ihr drei hättet es also nach den ersten 10 Kommentaren einfach damit
belassen können, denn da war im Prinzip schon alles gesagt.
> Alle anderen hier interessiert dein Bug einen (vom Moderator zensiert).
Der Aufstand von euch drei und die ganze Fragerrei beweist das
Gegenteil.
> "Ansprechen" kannst du natürlich viel, aber davon ändert sich rein gar> nichts.
Und mehr habe ich auch nicht gemacht und mehr war auch nicht mein Ziel.
Aber wenn ihr ständig nachfragt, gebe ich natürlich Antwort.
Leute, wenn wir, also Wilhelm M., Hmmm, Jörg W., MaWin und ich früher
zusammen im Sandkasten gespielt hätten, dann wäre das bestimmt eine
riesen Gaudi geworden. :p
Für alle, die mit der korrekten Formulieren eines simple-commands in
shell-language Probleme haben (Motivation dieses Threads), dem sei
"fuck" empfohlen:
https://github.com/nvbn/thefuck
(hilft in diesem speziellen Fall natürlich auch nicht, trotzdem ganz
lustig)
Wilhelm M. schrieb:> https://github.com/nvbn/thefuck>> (hilft in diesem speziellen Fall natürlich auch nicht, trotzdem ganz> lustig)
Brauchst halt für die Shell nen Befehl, der den vorherigen Befehl
rückgängig macht.
Also so ne Art multiple undo/redo Funktion, wie bei einem Texteditor.
Das wäre doch mal.
Yalu X. schrieb:> Jetzt würde mich doch mal ganz brennend interessieren, wie viele KLOC> oder gar MLOC du durch den vermeintlichen Clang-Bug verloren hast, dass> du deswegen so einen Aufstand machen musst ;-)
Außer einem für das erste Posting erstellten kurzen Testcode bestehend
aus einem einfachen:
<c>
#include <stdio.h>
int main(){
printf("Hallo\n");
return 0;
}
</c>
keinen.
Wie schon gesagt nutze ich gcc und bei ernsthaften Projekten habe ich
ohnehin Makefiles und Projektdateien.
Moin, -
wenn man ein richtiges Betriebssystem benutzt, gibt es noch mehr
Moeglichkeiten:
1
$typehello.c
2
#include<stdio>
3
4
intmain(){
5
printf("Hallo World\r\n");
6
return0;
7
}
Compile und Link:
1
$cc/version
2
CompaqCV6.4-005onOpenVMSVAXV7.3
3
$cchello.c
4
$linkhello.obj/exec=hello.c
Der Linker erstellt das Exec mit dem Namen hello.c, ausfuehren geht
latuernich:
1
$runhello.c
2
HalloWorld
Aber OpenVMS hat Versionen:
1
$dir/size
2
3
DirectoryUSER$DISK:[TOM.TMP]
4
5
HELLO.C;24
6
HELLO.C;11
7
HELLO.EXE;14
8
HELLO.OBJ;31
9
Totalof4files,10blocks.
Das hello.c mit der Version-nummer 2 ist das Executable. Meinen Source
koennte ich mit einem freundlichen
1
purge/log
loeschen.
Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber
bei Microsoft-Produkten oder bei Linux nicht angekommen (es gibt eine
Kruecke bei emacs, das ist aber eine Kruecke).
Genug erzaehlt von der guten alten Zeit[TM].
Gruesse
Th.
Lustig, sowas habe ich bei VMS' (mehr oder minder) Vorgänger RSX-11
gehabt, aber "pip /pu" war dort eins der am häufigsten benutzten
Kommandos, denn schließlich hatte eine Disk damals nur 4800 Blöcke, also
2400 KiB. Ja, KiB, nicht MiB …
Aber sowas wie eine Kommandozeilen-History oder TAB completion gab's da
natürlich eh nicht. :)
Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf
der Tastatur gesucht haben.
Aber Du hast schon recht, heute sind einige Sachen einfacher. Und vor
allen Dingen kann man mit relativ wenig Aufwand alte Rechner simulieren
(http://simh.trailing-edge.com/), daher habe ich eine Vax mit
Gigabit-Anschluss (die spielen aber auch zusammen mit den realen
10-MBit-Geraeten).
bis denne
Th.
Thomas W. schrieb:> daher habe ich eine Vax mit Gigabit-Anschluss
:-)
Ich habe mal irgendwann ein RSX-11 im Simulator laufen lassen, aber ich
gebe zu, ich finde mich kaum noch zurecht – obwohl ich es ein paar Jahre
lang recht aktiv benutzt habe. Außerdem fehlen natürlich solche Dinge
wie Compiler. Wir hatten damals GRW-Pascal (wenn ich mich recht
erinnere). Interessant, dass es nach 40 Jahren davon nicht irgendwo
einfach öffentlich runterladbare Kopien gibt (oder ich hab sie nicht
gefunden).
Nano schrieb:> Leute, wenn wir, also Wilhelm M., Hmmm, Jörg W., MaWin und ich früher> zusammen im Sandkasten gespielt hätten, dann wäre das bestimmt eine> riesen Gaudi geworden. :p
Ich kann es mir lebhaft vorstellen: "aber Mutti, er hat doch
angefangen...". ;-)
Thomas W. schrieb:> Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber> bei Microsoft-Produkten oder bei Linux nicht angekommen (es gibt eine> Kruecke bei emacs, das ist aber eine Kruecke).
Das Versionsierungsfeature würde mir gefallen.
Gab es Pläne das mal nach Linux zu portieren und falls ja, was ist
daraus geworden?
Was sagte Linus Trovald und sonstige wichtige Kernelentwickler dazu?
Thomas W. schrieb:> Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf> der Tastatur gesucht haben.
Also ich finde meine Tasten auf der Tastatur auch im dunkeln, aber finde
die Kommandozeilenhistory unglaublich praktisch, da sie einem die
Tipparbeit abnimmt, zuvor eingegebenes nochmal einzutippen.
Warum sollte man 100 Zeichen eintippen (z.b. bei tiefen Verzeichnissen
mit aussagekräftigen Namen), wenn es mit bspw. 3 Tastenanschlägen auch
getan wäre?
Was für eine schöne Doku völlig außer Rand und Band geratener
Programmierwerkzeuge! Die Lücken die das eine reißt muß das nächste
schließen usw. usf. Krebsartig wuchernde Sprachbürokratie ohne Ende.
Nano schrieb:> Thomas W. schrieb:>> Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf>> der Tastatur gesucht haben.>> Also ich finde meine Tasten auf der Tastatur auch im dunkeln, aber finde
Ctrl-B (oder Up Arrow) hat OpenVMS auch (20 Kommandos bei der VAX).
Gruesse
Th.
Nano schrieb:> Thomas W. schrieb:>> Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber>> Das Versionsierungsfeature würde mir gefallen.> Gab es Pläne das mal nach Linux zu portieren und falls ja, was ist> daraus geworden?> Was sagte Linus Trovald und sonstige wichtige Kernelentwickler dazu?
Da es sich im wesentlichen ein Filesystem-Feature ist: Nichts.
Wenn Du ein wenig Interesse hast: Es gibt ein Wikipedia-Artikel ueber
das Filesystem (Files-11, https://en.wikipedia.org/wiki/Files-11) der
technisch genug ist um die Konzepte zu verstehen. Wenn Du mehr wissen
willst, kannst Du Dich mit der "gray Wall" auseinander setzen
(https://commons.wikimedia.org/wiki/File:Vax-vms-grey-wall.jpg).
Gruesse
Th.
Linux hat seit 2.irgendwas das NILFS an Bord.
Damit kann nichts verloren gehen, weil nie gelöscht wird. Hat man
versehentlich eine Datei überschrieben, mountet man sich einfach den
Stand zwei Minuten vorher und kann sie wiederholen.
Thomas W. schrieb:> Wenn Du ein wenig Interesse hast: Es gibt ein Wikipedia-Artikel ueber> das Filesystem (Files-11, https://en.wikipedia.org/wiki/Files-11) der> technisch genug ist um die Konzepte zu verstehen.
Besten Dank.
Ich werde das mal durchlesen.
Jörg W. (dl8dtl) (Moderator) schrub
> Kommandos, denn schließlich hatte eine Disk damals nur 4800 Blöcke, also> 2400 KiB. Ja, KiB, nicht MiB …
Google "KiB"
Kib
Kíb
Substantiv, maskulin [der]landschaftlich
1.
Zorn
2.
Gezänk
Google "KB"
kB, KB
Abkürzung
Kilobyte
------
Ich weiß nicht ob's an meinem Alter liegt, aber ich kann mich an "KiB"
genauso wenig wie Google gewöhnen. Gute alte Zeit.
;)
PS: Habt ihr eigentlich keine anderen Probleme?
ach egal schrieb:> Ich weiß nicht ob's an meinem Alter liegt, aber ich kann mich an "KiB"> genauso wenig wie Google gewöhnen. Gute alte Zeit.
Die Idee ist ja an sich ok. Ich kann mich nur irgendwie nicht an das
Babysprech gewöhnen.
Rolf M. schrieb:> Ich kann mich nur irgendwie nicht an das Babysprech gewöhnen.
Geht mit der Zeit. Irgend'ne Unterscheidung braucht man halt,
insbesondere, seit die Festplattenhersteller den vorherigen Konsens,
dass alles in 2^10, 2^20 etc. angegegen wird, aufgegeben haben, damit
ihre Gigabytezahlen netter aussehen.
Also zum eigentlichen Thema: vermutlich ist es ein Bug ist, aber wie
groß ist dessen Relevanz? Wenn das ding seit Urzeiten im Clang drin ist,
und noch keiner danach gekräht hat bis jetzt, scheint die Notwendigkeit
ja nicht so hoch zu sein... ^^
Aber zurück zur Technik:
Guck dir mal Automake/Autoconf und Gedönse an, was die mit ihrem
./configure-Scripts erstmal abkläppern... da wird geguckt, was die libc
bei welchen Funktionen macht, ob der Compiler dies und das und jenes
kann usw. usf. -> um Eigenschaften von Compilern, Binutils, Shells usw.
zu abstrahieren, wurde ja sowas wie Automake/Autoconf bzw. CMake
überhaupt erschaffen.
Soll heißen, lieber fix nen kleines CMake-Projekt aufgesetzt und fertsch
ist die Laube.
Sicher, für reine Makefile-Projekte mag es schon ärgerlich sein, wenn
was kaputt geht. Ist aber auch ne Frage, wie bzw. ob man
Schreib/Lesezugriffe im Folder zulassen will. Was ich meine:
Bei CMake wird auch zu Out-Of-Source-Builds mit separatem Verzeichnis
geraten, was man btw. spätestens dann machen sollte, wenn man (a) die
selben Sourcen für unterschiedliche Ziele bauen will (Debug/Release,
oder x86,x64,arm) oder (b) seinen Source-Ordner sauber halben will, ohne
sich den Aufwand großer Makefile-Magie machen zu müssen (-> einfach
Buildfolder löschen). Das Thema VCS als Absicherung gegen versehentliche
Änderungen wurde ja schon genannt.
Abgesehen davon hast du, wie auch schon genannt, selbst wenn der
Compiler perfekt das fehlerhafte Argument erkennt, nen Buildfehler
drin. Praktisch gesehen also gehupft wie gesprungen, ob der Buildfehler
nun hier oder da passiert. Besser erkennbar würden solche Fehler durch
besseres Argumentparsing - mehr aber auch nicht.
Nano schrieb:> Mehr muss ich dazu nicht sagen, oder?>> Und seit wann gibt es clang? Sind doch jetzt schon sicher ein paar> Jahre.
Wo ist denn das Problem? Der Compiler macht was ihm gesagt wird.
Klar ist es schön, wenn der Compiler mitdenkt, aber darauf würde ich
mich nicht verlassen.
Nano schrieb:> Außer einem für das erste Posting erstellten kurzen Testcode bestehend> aus einem einfachen:>> #include <stdio.h>> int main(){> printf("Hallo\n");> return 0;> }>> keinen.
Kein Problem, Du hättest dafür einfach das Kommando, mit dem Du den
"kurzen Testcode" erzeugt hast, mit CURSOR-UP in der Shell wiederholen
müssen:
1
echo -e '#include <stdio.h>\nint main (void)\n{\n printf ("Hello, World\\n");\n}' >test.c
Thread beobachten
Seitenaufteilung abschalten