Announcement: there is an English version of this forum on Hallo, ich will ein bisschen mit C rumspielen und habe deshalb unter Linux als Editor das Visual Studio Code über das Anwendungszentrum installiert. Das hat auch prima funktioniert, aber nun kann ich kein neues Projekt öffnen. Bei älteren Versionen von VS Code musste man, glaube ich, dafür einfach einen neuen Ordner anlegen und konnte dann die gewünschte Programmiersprache wählen. Diese Option finde ich bei der aktuellen Version leider nicht mehr. Kann hier jemand weiterhelfen? Außerdem benötigt man ja noch einen C-Compiler, um das Geschriebene auszuführen. Kann man einen C-Compiler direkt als Extension in das VS Code einbinden und welcher ist empfehlenswert (gibt es dort GCC)?
Chat GPT schon gefragt? Bei mir hat cGPT ca 3 Seiten rausgespuckt. Habe nur dein Text copy pastet.
Wenn man nur zum "rumspielen" so eine fette IDE will, na gut. Ich persönlich würde ja den GCC Compiler, ggf. make und einen netten Editor nehmen. Wenn ich nur nach "VS Code" google kommen sofort YT videos mit "VS-Code for absolute beginners". Da schon mal reingeschaut?
Udo S. schrieb: > Ich persönlich würde ja den GCC Compiler, ggf. make und einen netten > Editor nehmen. VSCode ist nur ein Editor, sonst nichts. Ob nett, ist Ansichtssache. Und da unter Linux gcc und make dranzudengeln sollte man wohl hinbekommen. Dirk schrieb: > Bei älteren Versionen von VS Code musste man, glaube ich, dafür > einfach einen neuen Ordner anlegen und konnte dann die gewünschte > Programmiersprache wählen. Diese Option finde ich bei der aktuellen > Version leider nicht mehr. Keine Ahnung, ob das mal so war. Leg einen neuen Ordner an, mit einer Datei main.c drin, und öffne den Ordner dann in VSCode. Den Rest macht der dann schon selber. Oliver
:
Bearbeitet durch User
Udo S. schrieb: > Wenn man nur zum "rumspielen" so eine fette IDE will, na gut. Will bei der Gelegenheit auch mal VS Code ein bisschen kennenlernen. Udo S. schrieb: > Wenn ich nur nach "VS Code" google kommen sofort YT videos mit "VS-Code > for absolute beginners". > Da schon mal reingeschaut? Gute Idee! Hatte bisher nur VSC und C zusammen gesucht und nichts gefunden. Manchmal braucht man jemanden, der von außen auf die Sache schaut. Oliver S. schrieb: > Keine Ahnung, ob das mal so war. Leg einen neuen Ordner an, mit einer > Datei main.c drin, und öffne den Ordner dann in VSCode. Den Rest macht > der dann schon selber. Ebenfalls gute Idee! Vielen Dank!!!
Nemopuk schrieb: > Für AVR kann man es so nutzen: > http://stefanfrings.de/avr_ide/index.html#vscode Prima, Danke für den Link!
Sowas würde ich immer per CMake und CMakePresets.json machen, und Ninja Multi-Config als Build-Tool nutzen. Siehe dazu das angehängte Minimal-Demo-Projekt. Erst die nötigen Tools, insbesondere den Compiler, installieren:
1 | sudo apt-get install -y gcc g++ ninja-build cmake |
In VS Code die Extensions für CMake und C/C++ installieren: - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools Dann den Projekt-Ordner in VS Code öffnen. Es sollte dann automatisch nach einem Preset fragen, oder du kannst das Preset im CMake-Menü auswählen, unter "Configure". Unter Linux wähle dort "GCC_x64" aus. Genau so funktioniert es auch unter Windows. Installiere dazu den Microsoft-Compiler von hier (unter dem Punkt "Buildtools für Visual Studio 2026"): https://visualstudio.microsoft.com/de/downloads/#build-tools-for-visual-studio-2026 . Als Configure-Preset in VS-Code dann MSVC_x64 auswählen.
Niklas G. schrieb: > Installiere dazu den Microsoft-Compiler > MSVC_x64 Für welche Mikrocontroller ist der denn geeignet?
:
Bearbeitet durch User
Nemopuk schrieb: > Für welche Mikrocontroller ist der denn geeignet? Wer redet von Mikrocontrollern?
Um (wie der Threadstarter schreibt) unter Linux "ein bisschen mit C rumzuspielen" braucht man keinen Microcontroller. Allerdings muss man da i.d.R. auch keinen C-Compiler installieren, der sollte einfach schon da sein. Als Kommandozeilencompiler, versteht sich. Ist doch ein Linux-System. Auf CMake, Ninja und ähnliches kann man für den Anfang auch verzichten, selbst auf ein Makefile, wenn das Herumspielprogramm nur aus einem Sourcefile besteht. Das Makefile kann man sich selbst schreiben, wenns mehr Sourcefiles werden, damit kommt man auch schon recht weit.
Harald K. schrieb: > Auf CMake, Ninja und ähnliches kann man für den Anfang auch verzichten, > selbst auf ein Makefile, wenn das Herumspielprogramm nur aus einem > Sourcefile besteht. Kann man, macht's aber lästiger. Denn gerade VS Code hat eine enorm praktische CMake-Integration.
Niklas G. schrieb: > Denn gerade VS Code hat eine enorm > praktische CMake-Integration. Mag sein, aber das sind halt noch weitere Dinge, die es zunächst deutlich undurchschaubarer machen. CMake löst Probleme, die man in der Situation des Threadstarters nicht hat.
Harald K. schrieb: > CMake löst Probleme, die man in der Situation des Threadstarters nicht > hat. Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake kompilieren?
Oliver S. schrieb: > Mit einem makefile ganz bestimmt. > Oliver Dann kann man aber auch gleich eine CMakeLists.txt schreiben, die ist nämlich deutlich weniger kryptisch als ein Makefile und ganz zufällig auch automatisch portabel zu grundverschiedenen Compilern wie MSVC...
:
Bearbeitet durch User
Und ums noch abzurunden: zum „nur etwas rumspielen“ ohne Ambitionen, sich in die bekanntermaßen kryptischen Geheimnisse von make oder cmake einzuarbeiten, würde ich mir eine vollwertige IDE installieren, die das alles automatisch im Hintergrund abwickelt. Eclipse, QtCreator, Codeblocks, … C-Projekt anlegen, im automatisch angelegten main.c lostippen, build drücken, fertig. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > würde ich mir eine vollwertige IDE installieren, die das alles > automatisch im Hintergrund abwickelt. Eclipse, QtCreator, Codeblocks, Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist dass es sehr aktiv entwickelt wird. Es generiert zwar die Build-Dateien nicht automatisch, aber die kann man ja einfach aus meinem Demo-Projekt übernehmen, der Rest geht automatisch...
Oliver S. schrieb: > Und ums noch abzurunden: zum „nur etwas rumspielen“ ohne Ambitionen Dafür würde ich mir unter Linux einfach ein kleines Bash Script schreiben. Und auch keine IDE verwenden. Ist doch völlig egal wenn da 1-10 Sourcen immer wieder alle übersetzt werden. Nur falls der Rechner mind. 15 Jahre alt ist, dann merkt man das.
Etwas "rumspielen" kann man auch gut im Browser. Gibt einige GCC Compiler online. Dann braucht man garnichts installieren oder von make wissen. Beispiel: https://www.onlinegdb.com/online_c_compiler
:
Bearbeitet durch User
Niklas G. schrieb: > Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake > kompilieren? Natürlich. Du musst das, was passieren soll, als "task" in der Datei .vscode/tasks.json definieren. Da kannst Du auch von Hand den Compiler aufrufen (für 1-Source-Projekte), oder make, oder ein Batchfile/shellscript, oder was auch immer sonst Dir gefällt. Vscode ist da extrem flexibel.
Harald K. schrieb: > Natürlich. Du musst das, was passieren soll, als "task" in der Datei > .vscode/tasks.json definieren. Das ist nicht "auf Knopfdruck"... Und wenn man schon eine tasks.json anlegt kann man auch stattdessen eine CMakeLists.txt anlegen. 900ss schrieb: > Er möchte aber nur etwas mit C rumspielen. Aber in VS Code. Was auch sinnvoll ist, denn da geht es recht komfortabel.
Niklas G. schrieb: > Das ist nicht "auf Knopfdruck" Natürlich. Du kannst eine der Tasks mit einer Tastenkombination ausführen, es ist nicht nötig, sich da durch das Menü zu hangeln.
Harald K. schrieb: > Du kannst eine der Tasks mit einer Tastenkombination > ausführen, es ist nicht nötig, sich da durch das Menü zu hangeln. Kompilation per CMake ist sowieso per Default auf F7. Simpler geht's also nicht.
Niklas G. schrieb: > Kompilation per CMake Kommst Du in den CMake-Himmel, wenn Du genug missioniert hast? ;-)
Niklas G. schrieb: > Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist > dass es sehr aktiv entwickelt wird. Das ist ganz sicher kein Vorteil. Das merkt man, wenn man nach z.B. einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal nix funktioniert, weil zwischenzeitlich irgendwelche eigentlich völlig unwichtigen Kleinigkeiten geändert wurden, diese Änderungen aber ein erfolgreiches Build verhindern. Solche Bananen-Software nervt einfach mal nur unendlich. Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren, sonst ist es kein Werkzeug, sondern Spielzeug.
Ob S. schrieb: > Das merkt man, wenn man nach z.B. > einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal > nix funktioniert, VS Code ruft zum Bauen nur CMake auf, wenn das plötzlich nicht mehr gehen sollte kann man immer noch einfach CMake direkt aufrufen. Ob S. schrieb: > Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren Im Gegenteil müssen Entwicklungswerkzeuge regelmäßig aktualisiert werden, damit man damit auch neuere Technologien anwenden kann. Wie sollen sich sonst neue Technologien etablieren wenn die Entwicklungswerkzeuge die nicht einbinden können?
:
Bearbeitet durch User
Niklas G. schrieb: > Kompilation per CMake ist sowieso per Default auf F7. Nö, ist es nicht. Ist es nur, wenn man die CMake-Extension installiert hat.
Dirk schrieb: > (gibt es dort GCC)? Dort gibt es sogar GDB. Du könntest aber auch sowas hier nutzen: https://docs.redhat.com/de/documentation/red_hat_developer_tools/1/html-single/using_llvm_13.0.1_toolset/index Was hast du für ein Linux, denn die Entwicklungspakete sind nicht überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit an Board. P.S.: Als Editor könnte man auch noch CudaText ausprobieren, wenn man mit den Editoren in der Konsole nicht klarkommt.
:
Bearbeitet durch User
Danke noch für die vielen Antworten. Ich will es jetzt erst mal weiter mit JS-C versuchen. Niklas G. schrieb: > Erst die nötigen Tools, insbesondere den Compiler, installieren:sudo > apt-get install -y gcc g++ ninja-build cmake Hallo Niklas, ich gehe mal Schritt für Schritt vor, ninja-build cmake habe ich installiert. Dann wie hier angegeben https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools habe ich auch cMake installiert mit "ext install ms-vscode.cmake-tools". Aber jetzt soll noch das hier gemacht werden: Ensure that either you've added your CMake executable to your PATH, or you've adjusted the cmake.cmakePath setting to point to your CMake executable. Ich verstehe leider nicht, wo man das eintragen soll. Kannst du mir da weiterhelfen?
Dirk schrieb: > Ich verstehe leider nicht, wo man das eintragen soll. Unter Linux muss du da normalerweise nichts machen. Gib auf einem Terminal den "cmake" und den "ninja" Befehl ein; wenn beide gefunden werden, sollte es auch in VS Code funktionieren. Unter Windows mit den Visual Studio Build Tools muss es eigentlich auch sofort funktionieren, denn da ist ein CMake und ein Ninja mitgeliefert und VS Code bindet die automatisch ein.
:
Bearbeitet durch User
Ob S. schrieb: > Niklas G. schrieb: > >> Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist >> dass es sehr aktiv entwickelt wird. > > Das ist ganz sicher kein Vorteil. Das merkt man, wenn man nach z.B. > einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal > nix funktioniert, weil zwischenzeitlich irgendwelche eigentlich völlig > unwichtigen Kleinigkeiten geändert wurden, diese Änderungen aber ein > erfolgreiches Build verhindern. Aber ja doch, das ist unbedingt ein Vorteil. Ein aktives Projekt -- womöglich mit einer nicht minder aktiven Community -- hat eindeutige Vorzüge. Sonst ist es nämlich am Ende nur noch möglich, olles Gerümpel zu bauen, während moderne Technologien irgendwann nicht mehr genutzt werden können -- und auch für alte Sachen weder Bugfixes noch Optimierungen ankommen. > Solche Bananen-Software nervt einfach mal nur unendlich. > Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren, > sonst ist es kein Werkzeug, sondern Spielzeug. Was Du in Deiner grandiosen "Kompetenz" nicht verstehst, ist, daß es dabei nicht um Weiterentwicklung, sondern um Abwärtskompatibilität geht.
Rbx schrieb: > Was hast du für ein Linux, denn die Entwicklungspakete sind nicht > überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit > an Board. In modernen Linux-Distributionen wird das häufig nicht installiert. > P.S.: Als Editor könnte man auch noch CudaText ausprobieren, wenn man > mit den Editoren in der Konsole nicht klarkommt. Ja, oder UltraEdit, Programmer's Notepad, Kate, gedit, Emacs, vi(m), Atom... wobei Emacs und vi(m) wahlweise mit und ohne GUI benutzt werden können, aber gerade diese beiden sind vermutlich eher etwas für Enthusiasten. ;-)
Sheeva P. schrieb: > aber gerade diese beiden sind vermutlich eher etwas für > Enthusiasten. ;-) Zur Not ginge ja auch noch Nano. Finde ich witzig, dass du auch gedit aufführst. So gesehen könnte man auch Wine + Notepad++ anwerfen. Der Vorteil mit den Terminal-Editoren ist einfach, mehrere Terminals aufmachen, in dem einen editieren, in dem anderen übersetzen und linken. Ich hatte, als noch das XPS lief, Code::Blocks mit mingw auf Windows Vista installiert, aber die IDE wollte trotz eingetragener Pfade den mingw nicht finden oder nutzen. Da hatte ich dann lieber mit Eclipse geliebäugelt, Eclipse ist zwar etwas eigen, aber funktioniert wenigstes, wie man das erwartet, selbst wenn es unübersichtlich wird.. Aktuell mag das vielleicht ein wenig anders sein, aber ich bin tatsächlich in dem meisten Fällen auch mit gedit zufrieden. Meine ganzen Rust-Experimente schreibe ich bisher all da rein. Zumindest im Moment. Dieses ganze Absichern bei Rust und dann hinterher oder zwischendurch doch wieder untergraben (z.B. mit Address-Referenzen) usw. kann schon ganz schön anstrengend sein, da stören ablenkende IDEs oder ähnliches nur unnötig.
Niklas G. schrieb: > Dirk schrieb: >> Ich verstehe leider nicht, wo man das eintragen soll. > > Unter Linux muss du da normalerweise nichts machen. Gib auf einem > Terminal den "cmake" und den "ninja" Befehl ein; wenn beide gefunden > werden, sollte es auch in VS Code funktionieren. Unter Windows mit den > Visual Studio Build Tools muss es eigentlich auch sofort funktionieren, > denn da ist ein CMake und ein Ninja mitgeliefert und VS Code bindet die > automatisch ein. Vielen Dank für die schnelle Antwort und gute Idee mit dem Terminal! Wenn ich dort "cmake" eingebe, erscheint folgendes:
1 | Usage |
2 | |
3 | cmake [options] <path-to-source> |
4 | cmake [options] <path-to-existing-build> |
5 | cmake [options] -S <path-to-source> -B <path-to-build> |
6 | |
7 | Specify a source directory to (re-)generate a build system for it in the |
8 | current working directory. Specify an existing build directory to |
9 | re-generate its build system. |
10 | |
11 | Run 'cmake --help' for more information. |
Gebe ich "ninja" ein, erscheint:
1 | ninja: error: loading 'build.ninja': No such file or directory |
Irgendwas scheint mit der source directory noch nicht zu stimmen?!
Dirk schrieb: > Irgendwas scheint mit der source directory noch nicht zu stimmen?! Ne es ist alles richtig. Jetzt weißt du dass beide Programme korrekt installiert sind. Damit die beiden Tools etwas sinnvolles tun, muss man sie mit den entsprechend richtigen Parametern aufrufen. Das macht VS Code automatisch. Öffne mein Demo-Projekt in VS Code und du solltest es kompilieren können.
Sheeva P. schrieb: > Rbx schrieb: >> Was hast du für ein Linux, denn die Entwicklungspakete sind nicht >> überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit >> an Board. > > In modernen Linux-Distributionen wird das häufig nicht installiert. Ich nutze folgende Linux-Version: Ubuntu 25.10 Kernel: Linux 6.17.0-14-generic Architecture: x86-64
Dirk schrieb: > Sheeva P. schrieb: >> Rbx schrieb: >>> Was hast du für ein Linux, denn die Entwicklungspakete sind nicht >>> überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit >>> an Board. >> >> In modernen Linux-Distributionen wird das häufig nicht installiert. > > Ich nutze folgende Linux-Version: > > Ubuntu 25.10 > Kernel: Linux 6.17.0-14-generic > Architecture: x86-64 Dann Folgendes im Terminal ausführen:
1 | sudo apt-get update |
2 | sudo apt-get install build-essential |
Harry L. schrieb: > Dann Folgendes im Terminal ausführen: Unnötig. Wir haben bereits alles nötige installiert: Niklas G. schrieb: > sudo apt-get install -y gcc g++ ninja-build cmake Dirk muss einfach nur noch das Projekt öffnen.
Niklas G. schrieb: > Ne es ist alles richtig. Jetzt weißt du dass beide Programme korrekt > installiert sind. Vielen Dank, dann habe ich das falsch interpretiert, sorry. Also, habe deinen Ordner geöffnet, "GCC_x64" ausgewählt und das hat schon mal geklappt. Wenn ich dann auf main.c gehe (also dein "Hello, World"-Programm) und unter "Run" auf "Run without debuggin" klicke, kommt eine Fehlermeldung in einem weißen Fenster:
1 | (X) |
2 | Configured Debug Type 'cppvsdbg' is installed but not supported in this invironment. |
3 | <Abbrechen> <Open launch.json> |
Muss man das Programm anders compilieren/starten oder liegt der Fehler woanders?
Harald K. schrieb: > Allerdings muss man da i.d.R. auch keinen C-Compiler installieren, der > sollte einfach schon da sein. Als Kommandozeilencompiler, versteht sich. > Ist doch ein Linux-System. Das ist afair schon lange nicht mehr Standardmäßig mit dabei. Selbst wenn man nen Kernel selber bauen will, muss man alles nachinstallieren. GNU/Linux wird immer frickeliger.
Dirk schrieb: > Muss man das Programm anders compilieren/starten oder liegt der Fehler > woanders? Vielleicht ist manuelles compilieren für den Anfang doch besser. So musst Du noch die IDE mitlernen. "gcc main.c" ist da einfacher :P
Beitrag #8018555 wurde vom Autor gelöscht.
Dirk schrieb: > Configured Debug Type 'cppvsdbg' is installed but not supported in this > invironment. Ah, das geht so anscheinend nur unter Windows. Ersetze mal die .vscode/launch.json durch die hier angehängte. Kann es gerade nicht selbst unter Linux testen. Zuvor installiere noch den GDB: sudo apt-get install -y gdb Jens B. schrieb: > "gcc main.c" ist da einfacher :P Bringt hier nichts, da das Programm anscheinend bereits kompiliert wurde, nur die Launch Configuration in VS Code ist falsch.
Vielen Dank! Niklas G. schrieb: > Zuvor installiere noch den GDB:
1 | sudo apt-get install -y gdb |
Das gibt folgendes aus:
1 | Paketlisten werden gelesen… Fertig |
2 | Abhängigkeitsbaum wird aufgebaut… Fertig |
3 | Statusinformationen werden eingelesen… Fertig |
4 | gdb ist schon die neueste Version (16.3-1ubuntu2). |
5 | gdb wurde als manuell installiert festgelegt. |
6 | Auflösen von Abhängigkeiten… Fertig |
7 | 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert. |
> Ah, das geht so anscheinend nur unter Windows. Ersetze mal die > .vscode/launch.json durch die hier angehängte. Kann es gerade nicht > selbst unter Linux testen. Habe dann launch.json wie empfohlen ausgetauscht. Nun kommt folgende Fehlermeldung, wenn man auf "Run without debuggin" klickt:
1 | (X) |
2 | |
3 | launch: program 'null' does not exist |
4 | |
5 | <Abbrechen> <Open launch.json> |
Dirk schrieb: > Nun kommt folgende Fehlermeldung, wenn man auf "Run without debuggin" > klickt: Drück mal F7 zum Kompilieren und zeig die Ausgabe aus dem "Output" Fenster.
Niklas G. schrieb: > Drück mal F7 zum Kompilieren und zeig die Ausgabe aus dem "Output" > Fenster.
1 | [main] Building folder: /home/adxcf/C Programme meine/DemoProj1/build |
2 | [main] Configuring project: DemoProj1 |
3 | [proc] Executing command: /usr/bin/cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -S "/home/adxcf/C Programme meine/DemoProj1" -B "/home/adxcf/C Programme meine/DemoProj1/build" -G "Ninja Multi-Config" |
4 | [cmake] CMake Error: The current CMakeCache.txt directory /home/adxcf/C Programme meine/DemoProj1/build/CMakeCache.txt is different than the directory /home/adxcf/C Programme meine/DemoProj/build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt |
5 | [cmake] CMake Error: The source "/home/adxcf/C Programme meine/DemoProj1/CMakeLists.txt" does not match the source "/home/adxcf/C Programme meine/DemoProj/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. |
6 | [proc] The command: /usr/bin/cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -S "/home/adxcf/C Programme meine/DemoProj1" -B "/home/adxcf/C Programme meine/DemoProj1/build" -G "Ninja Multi-Config" exited with code: 1 |
Könnte es eventuell damit zu tun haben, dass ich einen identischen Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst wie "DemoProj")
Dirk schrieb: > Könnte es eventuell damit zu tun haben, dass ich einen identischen > Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst > wie "DemoProj") Das kannst ja leicht durch Umbennen testen. Vermutlich lautet die Antwort dann "nein".
Dirk schrieb: > Könnte es eventuell damit zu tun haben, dass ich einen identischen > Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst > wie "DemoProj") Äh, offenbar versucht es den Ordner "DemoProj1" zu kompilieren aber ist verwirrt weil das Projekt mal im Pfad "DemoProj" konfiguriert wurde. Vermutlich hast du den Ordner mal umbenannt?! Beende VS Code, lösche den "build" Ordner im Projekt, und öffne es neu in VS Code. PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im Projektpfad vermeiden, also "C Programme meine" ist nicht gut.
Niklas G. schrieb: > Dirk schrieb: >> Könnte es eventuell damit zu tun haben, dass ich einen identischen >> Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst >> wie "DemoProj") > > Äh, offenbar versucht es den Ordner "DemoProj1" zu kompilieren aber ist > verwirrt weil das Projekt mal im Pfad "DemoProj" konfiguriert wurde. > Vermutlich hast du den Ordner mal umbenannt?! > > Beende VS Code, lösche den "build" Ordner im Projekt, und öffne es neu > in VS Code. > > PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im > Projektpfad vermeiden, also "C Programme meine" ist nicht gut. Ah, ok, sowas hatte ich fast schon gedacht. Habe jetzt den Überordner noch mal neu aufgesetzt, diesmal direkt ohne Leerzeichen und deinen Ordner neu reingepackt und das json-File darin ausgetauscht wie oben beschrieben. Und jetzt geht es :))) Super, vielen herzlichen Dank für Deine Mühe und Geduld!!!!!!!!!!!!!!!!!! Ich bin so froh, dass es jetzt geht.
Dirk schrieb: > Und jetzt geht es :))) Tada 😁 Dirk schrieb: > Super, vielen herzlichen Dank Gern, viel Spaß 😉
Rbx schrieb: > Zur Not ginge ja auch noch Nano. Oder einer der tausend anderen Editoren, die es für Linux gibt. Nur... > Finde ich witzig, dass du auch gedit > aufführst. So gesehen könnte man auch Wine + Notepad++ anwerfen. ... warum man ausgerechnet eine Windows-Software in einem Nicht-Emulator benutzen wollen würde, erschließt sich mir nicht. > Der Vorteil mit den Terminal-Editoren ist einfach, mehrere Terminals > aufmachen, in dem einen editieren, in dem anderen übersetzen und linken. Äh, nein.
Fedora hat wohl kein Notepadqq als Package im Repo, nur eine veraltete Snap Version.
Niklas G. schrieb: > Harald K. schrieb: >> CMake löst Probleme, die man in der Situation des Threadstarters nicht >> hat. > > Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake > kompilieren? Gerade spaßeshalber probiert (weil ich, als eingefleischter Emacs-Fan :-), VScode dienstlich eh gerade offen hatte): * new window * open folder -> einen neuen angelegt * new text file * ein "hello world" hineingetippt * save as main.c * go -> debug Hat mich nach dem zu verwendenden Compiler gefragt, mir das Teil compiliert (irgendwie :), den GDB angeworfen, und alles laufen lassen. Da ich keinen breakpoint hatte, natürlich einfach einmal komplett durch. Also ja, geht, ohne Makefile, ohne CMake, ohne sonstwas. Die C/C++ extension muss man natürlich sinnvollerweise haben dafür.
:
Bearbeitet durch Moderator
ps: Es wirft dafür ein .vscode/tasks.json ab, in dem die relevanten Schritte beschrieben sind.
Niklas G. schrieb: > PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im > Projektpfad vermeiden, also "C Programme meine" ist nicht gut. Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das unter Linux doch nun wirklich kein Thema mehr sein. Oliver
Linux ist nicht das Problem. Nur der unbedarfte Nutzer. Jeder der Skripte schreibt hat das gelesen: Filenames and Pathnames in Shell: 2. How to do it wrongly (David A. Wheeler) https://dwheeler.com/essays/filenames-in-shell.html#wrong
:
Bearbeitet durch User
Oliver S. schrieb: > Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das > unter Linux doch nun wirklich kein Thema mehr sein. Linux an sich verkraftet sogar noch viel schlimmere Pfadnamen als Windows. Nur viele Skripte und auch Anwendungen eben nicht. Prinzipiell ist das lösbar, aber wer macht sich die Arbeit...
Niklas G. schrieb: > Oliver S. schrieb: >> Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das >> unter Linux doch nun wirklich kein Thema mehr sein. > > Linux an sich verkraftet sogar noch viel schlimmere Pfadnamen als > Windows. Nur viele Skripte und auch Anwendungen eben nicht. Prinzipiell > ist das lösbar, aber wer macht sich die Arbeit... Dann schreib ich’s mal etwas deutlicher: wenn in dem Kontext Linux/C/cmake/make/VSCode bei einem einfachen Hello world irgend etwas im Jahre 2026 nicht mit Leerzeichen im Pfad klarkommt, gehört das ab in die Tonne. Da gibts nix schönzureden, das muß funktionieren. Oliver
Oliver S. schrieb: > gehört das ab in die Tonne. Da gibts nix schönzureden, das muß > funktionieren. Dem geschenkten Gaul schaut man nicht ins Maul. Statt "in die Tonne" werden, könntest du dich an der Entwicklung der Korrektur beteiligen. Sozusagen als Dankeschön für das Geschenk.
:
Bearbeitet durch User
Oliver S. schrieb: > wenn in dem Kontext > Linux/C/cmake/make/VSCode bei einem einfachen Hello world irgend etwas > im Jahre 2026 nicht mit Leerzeichen im Pfad klarkommt, Es ist ja damit klar gekommen. CMake funktioniert unter Linux auch etwas besser als Windows. Aber früher oder später stolpert man über ein System das nicht damit klarkommt. Ich meine z.B. irgendwelche STM32 Tools mögen das nicht. Bevor man sich damit rumärgert die Ursache herauszufinden kann man auch direkt einen Projekte-Ordner ohne Leerzeichen anlegen.
Rbx schrieb: > Könntest du das vielleicht mal genauer erklären? Natürlich gerne. Schau, wenn ich ein Terminal-Fenster öffnen kann, dann kann ich Emacs oder vi(m) ebenfalls in der GUI starten. Das ist komfortabler, vor allem für die Augen, schließlich sitzt man beim Entwickeln oder komplizierten Konfigurationen mitunter stundenlang vor dem Ding. Und herumscrollen oder den Cursor schnell versetzen geht mit der Maus natürlich auch schneller. Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich keine passende GUI habe, also keinen X-Server oder keine ausreichende Netzwerkperformance für X-Forwarding habe. Das wäre mir, wenn ich irgendwo schnell eine kleine Änderung machen möchte, aber auf einem Boot mit schlechtem Netz unterwegs bin, oder im Bett liege und zu faul bin, zu einem Rechner zu laufen, oder wenn ich bei einem Kunden bin, der meinen Geräten zwar keinerlei Zugang zu seinem Netzwerk und zum Internet gewähren mag, mir aber einen Putty, MobaXTerm oder ssh(1) auf einem seiner eigenen Geräte zur Verfügung stellen kann. Und sicher auch noch in anderen Situationen, die ich schon wieder vergessen habe. In all diesen Fällen habe ich auch auf der Kommandozeile den Editor, den ich kenne, mit der Konfiguration, die ich seit Jahrzehnten pflege, inklusive all dem netten Zeug wie Syntax-Highlighting, Autocompletion, und so weiter. Yay! Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, und dazu bereit sind, sich einzuarbeiten. Emacs und vi(m) können tolle Sachen (einige davon habe ich sogar bei sehr leistungsfähigen IDEs wie Eclipse vermißt), aber die Lernkurve ist steil und die Unterschiede zu standardkonformen Programmen sind riesig. Ganz grundsätzlich glaube ich aber dennoch, daß Linux- oder UNIX-Interessierte zumindest die Basics des vi(m) lernen sollten. Der ist einfach immer vorhanden und hie und wieder auch mal der allerletzte Ausweg... :-)
Sheeva P. schrieb: > Der > ist einfach immer vorhanden und hie und wieder auch mal der allerletzte > Ausweg... :-) Na ja, einen Nano findet man eigentlich auch überall, und ctrl-s zum speichern und ctrl-x zum beenden kann man sich so gerade noch merken. Oliver
:
Bearbeitet durch User
Nemopuk schrieb: > Oliver S. schrieb: >> gehört das ab in die Tonne. Da gibts nix schönzureden, das muß >> funktionieren. > > Dem geschenkten Gaul schaut man nicht ins Maul. Ehrlich gesagt halte ich das für keine besonders kluge Argumentation. Auf der einen Seite provoziert sie den fehlerhaften Umkehrschluß, daß OpenSource-SW nicht leistungsfähig genug wäre und die Entwickler sich nicht darum kümmern, weil der Gaul ja geschenkt ist. Das ist natürlich Unsinn, denn wenn man das richtig macht, ist es überhaupt kein Problem. > Statt "in die Tonne" werden, könntest du dich an der Entwicklung der > Korrektur beteiligen. Sozusagen als Dankeschön für das Geschenk. Das wiederum provoziert womöglich den Fehlschluß, daß OpenSource-SW nur etwas für Leute sei, die daran mitwirken können. Das ist andererseits ebenso Unfug, denn viele Anwender von OpenSource-Software haben keine Ahnung, wie das geht, können ihre Aufgaben aber trotzdem mit ihrer Software erfüllen.
Oliver S. schrieb: > Na ja, einen Nano findet man eigentlich auch überall Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD?
Sheeva P. schrieb: > Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD? FreeBSD: pkg install nano Mache ich immer als ersten Schritt nach dem Installieren des Systems. Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" als Editor zu bezeichnen, habe ich nicht. Schon auf meinem ersten Computer vor 40 Jahren hatte ich einen Texteditor, der nicht wie edlin zwischen zwei Betriebsarten umgeschaltet werden musste. Damals, in der vorderen Altsteinzeit, als Tastaturen noch keine Cursortasten hatten, da mag so etwas nötig gewesen sein, aber schon der Apple II hatte Cursortasten. Und ein VT100 sowieso. Ich hab' ein bisschen das Gefühl, daß das ein Pseudo-Elitending ist, man findet sich cool und überlegen, weil man ein maximal unbedienbares Programm "gemeistert" hat. Meine Lebenszeit ist mir für derartiges zu schade. Und wer Wordstar gewohnt ist, kann sich nano auch anpassen; neuere Varianten unterstützen den Kommandozeilenparameter --modernbindings
Druck Dir doch ein cheat sheet aus dann gehörst Du wie ich mit zur Elite.
Alexander schrieb: > Druck Dir doch ein cheat sheet aus dann gehörst Du wie ich mit zur > Elite. Bwahahaha
Harald K. schrieb: > Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" > als Editor zu bezeichnen, habe ich nicht. Tja, und mich verwirren diese vorinstallierten und standardmäßig aktivierten Nanos, wenn ich einen vi erwarten würde. ;-) Ich habe den auch nie wirklich gemocht, aber das bissel, was man für grundlegendes Editieren damit braucht, hat man schnell drauf, und das sitzt auch nach vielen Jahren noch griffbereit.
Sheeva P. schrieb: > Nemopuk schrieb: >> Oliver S. schrieb: >>> gehört das ab in die Tonne. Da gibts nix schönzureden, das muß >>> funktionieren. >> >> Dem geschenkten Gaul schaut man nicht ins Maul. > > Ehrlich gesagt halte ich das für keine besonders kluge Argumentation. > Auf der einen Seite provoziert sie den fehlerhaften Umkehrschluß, daß > OpenSource-SW nicht leistungsfähig genug wäre und die Entwickler sich > nicht darum kümmern, weil der Gaul ja geschenkt ist. Das ist natürlich > Unsinn, denn wenn man das richtig macht, ist es überhaupt kein Problem. Eben. Zudem es da nicht um irgend eine BastelWastelBananensoftware geht, sondern um Linux. Das ist zwar Open Source, aber trotzdem eine hochprofesionelle Software, und vermutlich zudem Vorreiter von Leerzeichen in Pfaden und Dateinamen, seit Anbeginn der Zeitrechnung. Und für alles andere, was es darauf um Kompilieren von C-Programmen gibt, gilt das genauso. Oliver
Hallo, Jörg W. schrieb: > aber das bissel, was man für > grundlegendes Editieren damit braucht, hat man schnell drauf, und das > sitzt auch nach vielen Jahren noch griffbereit. Bezieht sich obiges auf nano oder vi? rhf
Sheeva P. schrieb: > Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten > empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, > und dazu bereit sind, sich einzuarbeiten. Willst du damit sagen, dass man sich beispielsweise bei Eclipse oder VS Code oder bei den Unix/Linux Shells nicht einarbeiten muss? Letztlich sind Vim oder Emacs gerade für Poweruser sehr wertvolle Werkzeuge, die muss man jetzt nicht automagisch in die Richtung "Spinner" lokalisieren. (übriges gab es vor einiger Zeit auch einen netten Artikel über den Emacs auf der Fedora-Seite). Ganz abgesehen davon reichen für Dirk schrieb: > ich will ein bisschen mit C rumspielen sogar Notepad oder Notepad++. Letzteres hat auch den Vorteil, viele Tabs aufmachen zu können, und so, wenn man Modul-Programm-Technisch unterwegs ist, eine ganz gute Übersicht haben kann. Notepad++ ist wohl nicht so ganz Wine-freundlich - aber das normale Notepad auf jeden Fall ;) (die Alternative zu Notepad++ wäre auf Linux SciTE - funktioniert zwar etwas anders als Notepad++, ist aber auch nicht schlecht.) Harald K. schrieb: > Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" > als Editor zu bezeichnen, habe ich nicht. Der Watcom-VI ist nicht ganz so schlimm. Das Problem bei den alten Editoren ist halt, du brauchst ähnlich viel Übungsaufwand wie beim akustischen Morse-Code lernen, oder beim Gitarre-Spielen Einstieg - und das ist eine Einstiegshürde, die sich vor allem für Poweruser lohnt (weil man ja sonst auch einige der Möglichkeiten gleich wieder vergisst). Letztlich: Vielleicht hilft es auch beim VI, wenn man die ersten gescheiterten Versuche der Bedienung schon hinter sich hat ;)
Roland F. schrieb: > Hallo, > Jörg W. schrieb: >> aber das bissel, was man für >> grundlegendes Editieren damit braucht, hat man schnell drauf, und das >> sitzt auch nach vielen Jahren noch griffbereit. > > Bezieht sich obiges auf nano oder vi? Da ich davor schrieb, dass Nano mich immer wieder verwirrt, sollte die Antwort klar sein. ;-)
Hallo, Jörg W. schrieb: > ...dass Nano mich immer wieder verwirrt... Deshalb hatte ich gefragt, mich verwirrt das dich Nano verwirrt. :-) Nano ist, vorsichtig formuliert, in meinen Augen recht schlicht. Da bleibt für Verwirrung eigentlich wenig Raum. Bei vi dagegen ist es genau umgekehrt, die dahinter stehende Bedienphilosophie ist für mich völlig unzugänglich. rhf P.S. Bei Taschenrechnern benutze ich andererseits ausschließlich UPN als als Eingabemethode und das ist für viele Andere ebenfalls völlig unzugänglich.
Roland F. schrieb: > Nano ist, vorsichtig formuliert, in meinen Augen recht schlicht. Da > bleibt für Verwirrung eigentlich wenig Raum. Verwirrend ist für mich bereits, wenn der Editor aufklappt und gefühlt die halbe Bildschirmfläche mit seinem Online-Manual füllt :-), wobei die Kommandos ja nun abseits jeglicher Standards sind. > Bei Taschenrechnern benutze ich andererseits ausschließlich UPN als als > Eingabemethode und das ist für viele Andere ebenfalls völlig > unzugänglich. Bei mir werkelt auch sowohl auf dem Desktop als auch Handy ein X48. Der richtige HP48 ist mir doch etwas zu klobig heutzutage, um ihn noch groß herumzutragen.
Jörg W. schrieb: > wobei die Kommandos ja nun abseits jeglicher Standards sind. --modernbindings Wer halt abseits der "Ich bediene nur und ausschließlich Unixoide Systeme"-Blase unterwegs ist, der ist schon dem Bedienstandard "Cursortasten bewegen den Cursor, ohne daß man zwischen Betriebsarten umschalten muss" begegnet. Sowas brauchten eigentlich nur Zeilenditoren wie Edlin ... Und daß man an termcap-Files herumschnitzen muss, weil natürlich das verwendete Terminal sich anders verhielt als die, die in der Standardkonfiguration vorhanden waren, das dürfte auch schon ein paar Tage her sein. (Mein erster Computer nutzte eine Art TVI950, das war der Befehlssatz der Grip von Conitec ... In der Firma, in der ich wenig später anfing zu arbeiten, gab es irgendeinen völlig obskuren Hausstandard einer längst vergessenen Firma aus Kanada. Aber einen Editor, der wusste, was Cursortasten sind)
Hallo, Jörg W. schrieb: > wobei die > Kommandos ja nun abseits jeglicher Standards sind. Ja, stimmt. Man kann aber in der Konfigurationsdatei "/etc/nanorc" einige Standardkommandos "freischalten". rhf
Angehängte Dateien:
-
exiting-vim.jpg
170 KB -
nano-1.png
130 KB -
nano-2.png
130 KB
Roland F. schrieb: > Ja, stimmt. Immerhin: Sie werden angezeigt. Man muss also keine man-Page bemühen, sondern für die allerwichtigsten Basics einfach nur hinschauen. Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel Platz weg. Das sind immerhin vier Zeilen, eine am oberen Bildschirmrand und drei am unteren. Hier zwei Bilder, wie das bei 80x25 aussieht: nano-1 zeigt die typische Belegung, nano-2 zeigt, was passiert, wenn man --modernbindings verwendet. (Und das ist die nano-Version, die man mit pkg install nano auf einem aktuellen FreeBSD erhält)
:
Bearbeitet durch User
Harald K. schrieb: > Und das ist die nano-Version, die man mit pkg install nano auf einem > aktuellen FreeBSD erhält Habe noch nie Bedarf gehabt, das auf einem FreeBSD zu installieren. :-) Wenn, dann installier ich mir einen Emacs, und wenn nicht, dann tut's der vi … Mit vim bin ich nie warm geworden, wenngleich der für Softwareentwicklung genauso taugen dürfte wie Emacs (und man heutzutage beide üblicherweise im GUI-Modus benutzt). VScode benutze ich vor allem beruflich, weil es meinen Kollegen noch am ehesten vermittelbar ist – und um es vorsichtig zu formulieren: Microsoft hat schon sehr viel schrecklicheres Zeug produziert als VScode. Für mich ist das immer noch das Beste aus dem Hause Microsoft seit dem m80 (Macro-80)¹. :-) ¹ https://en.wikipedia.org/wiki/Microsoft_MACRO-80
Jörg W. schrieb: > Habe noch nie Bedarf gehabt, das auf einem FreeBSD zu installieren. Ich installier mir das immer als erstes, weil "vi" einfach ... Wenn man früh genug die Gehirnwindungen angepasst bekommt, dann kann man sich daran gewöhnen und sich damit wohlfühlen. Das ist wohl wie bei Taschenrechnern, UPN oder nicht UPN. Die einen können Forth und Postscript lesen, die anderen nicht. Oder wie beim Autofahren; ist man früh genug auch mal in Großbritannien mit einem Auto gefahren, fällt einem die Umstellung nicht ansatzweise so schwer, wie wenn man das mit 20+ Jahren Fahrpraxis zum ersten Mal versucht.
Harald K. schrieb: > Wenn man früh genug die Gehirnwindungen angepasst bekommt, dann kann man > sich daran gewöhnen und sich damit wohlfühlen. Von "wohlfühlen" kann bei mir da auch keine Rede sein. In meiner allerersten Firma war ich der, der den vi am meisten gehasst hat, trotzdem kannte ich am Ende mehr Kommandos als meine Kollegen, die ihn damals wirklich für Softwareentwicklung genutzt haben. ;-) > Oder wie beim Autofahren; ist man früh genug auch mal in Großbritannien > mit einem Auto gefahren, fällt einem die Umstellung nicht ansatzweise so > schwer, wie wenn man das mit 20+ Jahren Fahrpraxis zum ersten Mal > versucht. In GB war ich nie, aber in ZA und Namibia. Fand ich im Großen und Ganzen nicht schwierig, man sitzt ja auf der anderen Seite und die anderen fahren auch alle so. :-) Einzig irgendwo in einem Wohngebiet ohne Verkehr beim Linksabbiegen fand ich mich dann mal auf der falschen Straßenseite wieder. Schwieriger fand ich das, als Fußgänger über die Straße zu gehen: links gucken, frei, rechts guck… hui, da huscht einer vor der Nase vorbei. :-/
Jörg W. schrieb: > Fand ich im Großen und > Ganzen nicht schwierig, man sitzt ja auf der anderen Seite und die > anderen fahren auch alle so. Ah ... ich mach' das mit meinem eigenen Auto. Da sitze ich, wo ich sonst auch sitze. (ist verständlicherweise in Südafrika & Co. weniger üblich, die Anfahrt ist doch etwas länger als nur bis Ijmuiden und rauf auf die Fähre nach Newcastle) Das erste Mal hab' ichs mit einem Fahrrad gemacht, ca. 2000 km quer durch England, Wales und Irland. Und: Ich liebe es. Vor allem Kreisverkehre. Oh, und das mit dem Linksabbiegen hatte ich auch mal, allerdings in Deutschland, nach einem längeren Urlaub in England. Ugh. Der Autofahrer, der mir da entgegengekommen ist, war leicht irritiert, aber glücklicherweise war da eine Fußgängerinsel mit abgesenktem Bordstein ... Dürfte knapp filmreif gewesen sein, die Aktion.
Jörg W. schrieb: > wobei die Kommandos ja nun abseits jeglicher Standards sind. Das ist ja Gott so Dank bei bei Emacs nicht der Fall ;) SCNR :)
900ss schrieb: > Das ist ja Gott so Dank bei bei Emacs nicht der Fall ;) Nö, dort ist alles Emacs-Standard. ;-) Im Ernst: Emacs war und ist an vielen Stellen durchaus ein Standard. Da er natürlich lange schon vor dem existierte, was dann spätere GUIs so gemacht haben, sollte es jetzt nicht so verwundern, dass sich diese unterscheiden. Dinge wie ^P und ^N für previous-line und next-line kannst du auch heute noch in jeder Bash so benutzen. Früher konnte man ab Cursor bis zum Ende der Zeile noch mit ^K in der URL-Zeile des Firefox löschen, aber das geht leider schon lange nicht mehr. Eigentlich schade, jetzt muss man das umständlich mit der Maus machen. Nano wiederum macht aber nichts davon, weder Emacs noch aktuelle GUI-Standards (zumindest eben nicht von Haus aus – Optionen wurden oben ja genannt).
Jörg W. schrieb: > Eigentlich schade, jetzt muss man > das umständlich mit der Maus machen. Links ist gar nicht so schlecht. Ist natürlich auch ein Ding, mit dem man sich beschäftigen muss. Kann aber schon Spass machen - je nachdem.
Jörg W. schrieb: > Früher konnte man ab Cursor bis zum Ende > der Zeile noch mit ^K in der URL-Zeile des Firefox löschen, aber das > geht leider schon lange nicht mehr. Eigentlich schade, jetzt muss man > das umständlich mit der Maus machen. Spricht was gegen Shift+End, gefolgt von einem Del, so wie in 99% aller Textfelder? OK, die Shift-Taste mitgezählt hast du 3 Tasten, aber das hättest du mit d$ auch. Eine Maus ist jedenfalls nicht notwendig.
:
Bearbeitet durch User
Le X. schrieb: > Spricht was gegen Shift+End, gefolgt von einem Del, so wie in 99% aller > Textfelder? Ist im Gegensatz zu ^K nicht in meine Finger verdrahtet :-), und hätte ich ohne deinen Hinweis jetzt auch nicht gekannt.
Jörg W. schrieb: > Ist im Gegensatz zu ^K nicht in meine Finger verdrahtet :-), und hätte > ich ohne deinen Hinweis jetzt auch nicht gekannt. Dafür wusste ich nicht dass ^P und ^N im Terminal funktionieren, ich hab dazu tatsächlich Cursortasten benutzt. Wir sind also quitt ;-)
Harald K. schrieb: > Sheeva P. schrieb: >> Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD? > > FreeBSD: pkg install nano > > Mache ich immer als ersten Schritt nach dem Installieren des Systems. In Deinem Wunschkonzert, ja, und ich installiere in meinem den Emacs. Aber ich arbeite oft auf Systemen, auf denen mir schlicht die Privilegien fehlen, etwas zu installieren. Jetzt rate mal, was deren große Gemeinsamkeit ist? Richtig: die haben alle einen vi. Alle. Ausnahmslos. Ohne was zu installieren. > Ich hab' ein bisschen das Gefühl, daß das ein Pseudo-Elitending ist, man > findet sich cool und überlegen, weil man ein maximal unbedienbares > Programm "gemeistert" hat. Es gibt gute Gründe, zumindest die Basisoperationen des vi(m) zu beherrschen, einen davon habe ich Dir gerade genannt: nämlich, daß er auf jedem unixoiden System bereits fix und fertig installiert ist. > Meine Lebenszeit ist mir für derartiges zu schade. Anscheinend ist Dir Deine Lebenszeit auch zu schade, einen Thread zu lesen und zu verstehen, bevor Du hinein klugscheißt. Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal der Standard unter unixoiden Systemen ist.
Oliver S. schrieb: > Eben. Zudem es da nicht um irgend eine BastelWastelBananensoftware geht, > sondern um Linux. Das ist zwar Open Source, aber trotzdem eine > hochprofesionelle Software, und vermutlich zudem Vorreiter von > Leerzeichen in Pfaden und Dateinamen, seit Anbeginn der Zeitrechnung. > Und für alles andere, was es darauf um Kompilieren von C-Programmen > gibt, gilt das genauso. Nichtsdestotrotz bleiben Leerzeichen in Pfaden schlechter Stil.
Sheeva P. schrieb: > Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden > hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies > ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal > der Standard unter unixoiden Systemen ist. Dem TE eher nicht: Dirk schrieb: > Kann man einen C-Compiler direkt als Extension in das VS Code einbinden > und welcher ist empfehlenswert (gibt es dort GCC)?
Rbx schrieb: > Sheeva P. schrieb: >> Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten >> empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, >> und dazu bereit sind, sich einzuarbeiten. > > Willst du damit sagen, dass man sich beispielsweise bei Eclipse oder VS > Code oder bei den Unix/Linux Shells nicht einarbeiten muss? Habe ich das denn gesagt? Nein. Bitte betrachte dies als starkes Indiz dafür, daß ich NICHT das sagen wollte, was Du mir unterstellst. > Letztlich sind Vim oder Emacs gerade für Poweruser sehr wertvolle > Werkzeuge, die muss man jetzt nicht automagisch in die Richtung > "Spinner" lokalisieren. Genau darum habe ich nicht "Spinner", sondern "Enthusiasten" geschrieben. Wenn Du meine Ausführungen gelesen und verstanden hättest, dann wüßtest Du, daß ich selbst einer dieser Poweruser mit Emacs und Shell bin. Deswegen weiß ich, daß das eine Einarbeitung erfordert, die über ein bisschen Eclipse und Co. weit hinausgeht. Und selbst danach muß man sich immer wieder umgewöhnen, weil Emacs und vi(m) für nahezu alles ganz andere Shortcuts benutzen als die meisten anderen Programme. Immerhin, viele Shortcuts des Emacs funktionieren auch in der Bash einwandfrei, yay! Ja, der Emacs und der vi(m) sind insofern ein bisschen unbequem. Also stellt sich die verständliche Frage, warum manche Leute sie trotzdem benutzen. Dazu werden die meisten ihrer Nutzer vermutlich leicht unterschiedliche Antworten geben, die aber alle auf denselben Kern hinauslaufen: weil es sich für diese Benutzer trotzdem lohnt, ganz einfach. > Ganz abgesehen davon reichen für > > Dirk schrieb: >> ich will ein bisschen mit C rumspielen > > sogar Notepad oder Notepad++. Letzteres hat auch den Vorteil, viele Tabs > aufmachen zu können, Das können Kate und Geany natürlich auch, und bestimmt noch etliche andere der Editoren, die nativ unter Linux laufen. > Notepad++ ist wohl nicht so ganz Wine-freundlich - aber das normale > Notepad auf jeden Fall ;) Ehrlich gesagt, fehlen mir die Worte, um zu beschreiben, für wie bescheuert ich die ganze Idee halte, ausgerechnet unter Linux ein Notepad unter Wine zu benutzen. Oder eine andere Software, für die es ein ähnlich leistungsfähiges oder gar viel mächtigere Äquivalente unter Linux gibt. Wine ist ein Notbehelf, mit dem man die (relativ wenigen) Lücken stopfen kann, wenn es keine Linux-Software für eine bestimmte Aufgabe gibt. Aber es ist und bleibt nur eine Notlösung, nicht mehr. Bei einem sehr komplexen Programm, das hohe Einarbeitungsaufwände erfordert, könnte ich einen Ansatz mit Wine auch noch verstehen. Womöglich erleichtert das den Umstieg oder einen häufigen Wechsel zwischen den Systemen. Aber bei einem so simplen Programm wie einem Texteditor? Ernsthaft?
Harald K. schrieb: > Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung > arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel > Platz weg. Und mit Termux auf dem Smartphone erstmal...
Le X. schrieb: > Dafür wusste ich nicht dass ^P und ^N im Terminal funktionieren, ich hab > dazu tatsächlich Cursortasten benutzt. Da geht noch viel mehr, siehe [1]. Dort nicht beschriftet, hier aber sehr oft benutzt: "Esc + .", das übernimmt das letzte Argument des vorigen Kommandos in die aktuelle Position, bei Wiederholung das vorletzte, das vorvorletzte... you get the idea. HF! :-) [1] https://gist.github.com/tuxfight3r/60051ac67c5f0445efee
Le X. schrieb: > Sheeva P. schrieb: >> Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden >> hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies >> ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal >> der Standard unter unixoiden Systemen ist. > > Dem TE eher nicht: > > Dirk schrieb: >> Kann man einen C-Compiler direkt als Extension in das VS Code einbinden >> und welcher ist empfehlenswert (gibt es dort GCC)? Okay, stimmt, aber AFAIK ist diese Frage bereits positiv beantwortet worden. Allerdings hätte ich, da hast Du Recht, präzisieren sollen: nicht in diesem Thread, sondern in dem Subthread, in den mein Vorredner eingeworfen hatte. Lieben Dank für die Klarstellung! :-)
Harald K. schrieb: > Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung > arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel > Platz weg. Da nano nie wirklich zum produktiven Arbeiten konzipiert war, sondern damit jeder mal eben schnell eine /etc/fstab flicken kann o.ä., ist das schon total in Ordnung. Die eingeblendeten Shortcuts sind da enorm hilfreich. Wer wirklich effizient Text auf dem Terminal bearbeiten will hat genug Alternativen. Sheeva P. schrieb: > Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus > haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich > keine passende GUI habe, also keinen X-Server oder keine ausreichende > Netzwerkperformance für X-Forwarding habe. VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft und per SSH eine Verbindung zum Target aufbaut. Dort muss die Server-Komponente von VS Code laufen, die aber keine GUI braucht. Serverseitig sind diverse OSe und Architekturen unterstützt, aber natürlich nicht jedes erdenkliche exotische System: https://code.visualstudio.com/docs/remote/ssh#_system-requirements Die lokale GUI läuft dann schön flüssig mit allgen gewohnten Einstellungen, Erweiterungen etc., während der Code, Compiler und Kompilate nur remote auf dem Target liegen.
Niklas G. schrieb: > VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft > und per SSH eine Verbindung zum Target aufbaut. Alternativ kann man vscode auch zu "crossentwicklung" verwenden, dazu muss auf dem Target nur ein lldbserver laufen. Compiler etc. laufen lokal. Hat den Vorzug, daß man auf dem (eher leistungsfähigeren) Arbeitsplatzrechner arbeiten kann, und auf dem (im Embedded-Bereich eher schwachbrüstigen Target) Debuggen kann. Für die lldb-Integration gibts eine Extension. Ich nutze sowas, um vscode unter Windows laufen zu lassen, das Target ist ein Raspberry Pi mit FreeBSD.
Niklas G. schrieb: > Sheeva P. schrieb: >> Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus >> haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich >> keine passende GUI habe, also keinen X-Server oder keine ausreichende >> Netzwerkperformance für X-Forwarding habe. > > VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft > und per SSH eine Verbindung zum Target aufbaut. Dort muss die > Server-Komponente von VS Code laufen, die aber keine GUI braucht. Ich fürchte, Du hast den Anwendungsfall "keinen X-Server" verfehlt. Zudem würde ich niemals in meinem Leben auf die Idee kommen, meine Server mit der Software eines der übelsten Datenkraken der Welt zu infizieren. Schon gar nicht, wenn er den Gesetzen des orangenen Haßpredigers unterliegt. Schon gar nicht, um damit so simple Aufgaben wie das Editieren von Textdateien zu ermöglichen. Mein Emacs hat für so etwas übrigens TRAMP [1] bereits fertig integriert, das läuft über SSH und funktioniert auch prima mit verschiedenen Möglichkeiten zur Privilegienerweiterung wie su(1), sudo(1) und weiteren. [1] https://www.gnu.org/software/tramp/ > Die lokale GUI läuft dann schön flüssig mit allgen gewohnten > Einstellungen, Erweiterungen etc., während der Code, Compiler und > Kompilate nur remote auf dem Target liegen. Code und Compiler auf einem Server... o tempora, o mores.
Sheeva P. schrieb: > Zudem würde ich niemals in meinem Leben auf die Idee kommen, meine > Server mit der Software eines der übelsten Datenkraken der Welt zu > infizieren. Man kann Paranoia auch über das Krankhafte hinweg bis ins final Pathologische steigern. vscode ist ein Open-Source-Projekt.
Sheeva P. schrieb: > Genau darum habe ich nicht "Spinner", sondern "Enthusiasten" > geschrieben. Nun ja, Verallgemeinerung bleibt Verallgemeinerung. Man könnte noch deutlich schlimmeres Andichten - schreibe ich hier aber lieber nicht. So also finde dich damit ab und schau lieber mal die Herkunft von Enthusiasmus und die die Etymologie des Begriffes nach. Sheeva P. schrieb: > weil es sich für diese Benutzer trotzdem lohnt, ganz > einfach. Beispielsweise Java mit VI programmieren. Man kann die ganzen Sch..Begriffskonstrukte beim Programmieren schnell mal umbenennen - und wenn es zum Übersetzen geht, kann man den Vorgang genau so schnell zurücknehmen, aber wegen den Umdeutungen kann zwischendurch eben schon ein wenig Spaß damit haben ;) Sheeva P. schrieb: > Wenn Du meine Ausführungen gelesen und verstanden hättest, dann wüßtest > Du, daß ich selbst einer dieser Poweruser mit Emacs und Shell bin. Ist mir schon klar, und ich kann schon ganz gut einschätzen, warum der Emacs so beliebt ist. Letztlich verstehe ich den Witz über Editoren auf xkcd* ja auch sehr gut - aber du erwartest, dass andere Leser hier gewissermaßen zwischen den Zeilen erkennen, was dich vom Emacs so abhängig macht. Übrigens, die Nähe zu Python und zu Tramp lassen erkennen, dass es dir um Realtime eher weniger geht. Naja, man kann ja Wissen- Könnenslücken haben, ist ja nicht so schlimm. Und hinsichtlich des Lernens - die KI hilft mir mit Rust so gut, dass ich mir nicht verkneifen kann, auch etwas über Assembler in Linux zu erfragen. Hach.. *die Nummer hier ist auch gut: https://xkcd.com/862/ Sheeva P. schrieb: > Ehrlich gesagt, fehlen mir die Worte, um zu beschreiben, für wie > bescheuert ich die ganze Idee halte, ausgerechnet unter Linux ein > Notepad unter Wine zu benutzen. Notepad kommt automatisch mit der Wine-Installation mit. Darüber hinaus ist Notepad sehr praktisch, um gewisse Schwierigkeiten mit Wine hinsichtlich 32/64 Bit zu überprüfen. Also eher ein Kontrollmonitor, wenn man so will. Backtrack hatte mal das Arbeiten mit Notepad als Editor in Linux vorgestellt, oder auch wie gut man mit IDA unter diesen Bedingungen arbeiten kann. Genaugenommen hatten die Backtrack-Entwickler mir so die Scheu vor diesem oder jenem Hindernis zu Linux genommen und mir so eigentlich auch den Frust über Sidux gemindert. Sheeva P. schrieb: > Wine ist ein Notbehelf, Das ist auch wieder so ein Allgemeinplatz (und abwertend auch noch), der sich so anhört, als wären alle Angelegenheiten mit Emulatoren oder mit Virtuellen Sachen doof.
Beitrag #8021920 wurde vom Autor gelöscht.
Sheeva P. schrieb: > Ich fürchte, Du hast den Anwendungsfall "keinen X-Server" verfehlt. Auf dem Server läuft dann natürlich immer noch kein X-Server. Die GUI ist ja wie gesagt komplett lokal. Sheeva P. schrieb: > Code und Compiler auf einem Server... Code und Compiler lokal zu haben ist natürlich noch einfacher: Harald K. schrieb: > Für die lldb-Integration gibts eine Extension.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.