Bin seit einiger Zeit schon mit Linux Mint Cinnamon 19.2 unterwegs und hatte gestern mal versucht das Hterm-Terminalprogramm zu installieren. Die neueste Linux-Version von http://www.der-hammer.info/terminal/index.htm gesaugt, mit tar -xzf hterm.tar.gz entpackt und dann versucht, das bin-Programm zu starten. Bei früheren Debianversionen war das kein Problem, doch bei Mint tat sich nichts. Habe das Hterm zur Zeit zwar nur auf älteren Laptops im Einsatz, welche vor Ort bei den verbauten Schaltungen noch gut zu gebrauchen sind, doch sollte es doch auf aktuellen Linux-Versionen auch laufen. Hat da jemand für Mint eine Lösung parat? Gruß Hans
Laß es mal auf der Kommandozeile laufen, dann sieht man die fehlenden libs. Das wird Fleißarbeit. Man merkt daß die SW seit >10 Jahren nicht mehr gepflegt wurde. Mir ist es das nicht Wert. Alternativen: gtkterm und moserial Gerade mal getestet: Unter wine läuft er.
:
Bearbeitet durch User
Da fehlen eine Menge 32Bit-Libraries:
1 | $ ldd hterm | grep 'not found' |
2 | libgtk-x11-2.0.so.0 => not found |
3 | libgdk-x11-2.0.so.0 => not found |
4 | libatk-1.0.so.0 => not found |
5 | libgdk_pixbuf-2.0.so.0 => not found |
6 | libfontconfig.so.1 => not found |
7 | libXext.so.6 => not found |
8 | libXrender.so.1 => not found |
9 | libXi.so.6 => not found |
10 | libXrandr.so.2 => not found |
11 | libXcursor.so.1 => not found |
12 | libXfixes.so.3 => not found |
13 | libpango-1.0.so.0 => not found |
14 | libX11.so.6 => not found |
15 | libgobject-2.0.so.0 => not found |
16 | libgmodule-2.0.so.0 => not found |
17 | libgthread-2.0.so.0 => not found |
18 | libglib-2.0.so.0 => not found |
19 | libXinerama.so.1 => not found |
20 | libSM.so.6 => not found |
21 | libpng12.so.0 => not found |
22 | libexpat.so.1 => not found |
23 | libstdc++.so.6 => not found |
Bei mir reichte folgende Zeile: sudo apt-get install libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386
Danke für die Antworten. Nach sudo apt-get install libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386 ging noch nichts mit hterm &. Komischerweise hans@Lati:~$ hterm & [1] 2304 hans@Lati:~$ bash: /usr/local/bin/hterm: Datei oder Verzeichnis nicht gefunden cd /usr/local/bin/ [1]+ Exit 127 hterm (wd: ~) (gegenwärtiges Arbeitsverzeichnis ist: /usr/local/bin) hans@Lati:/usr/local/bin$ ls apt boot gnome-help highlight-mint mint-sha256sum search upload.new asem customiz hexbin hterm reset51 upload yelp hans@Lati:/usr/local/bin$ hterm & [1] 2309 bash: /usr/local/bin/hterm: Datei oder Verzeichnis nicht gefunden Da fiel mir ein, daß ich ja keinen USB-seriell-Adapter angeschlossen hatte und sonst auch kein COM da ist. gtkterm konnte ich problemlos installieren und starten, und das hat dann auch gleich gemerkt, daß da was fehlt..... Danke noch mal, sollte noch weitere Hilfe nötig sein, melde ich mich noch mal, Gruß Hans
Möglicherweise hast Du ein reines 64Bit-System und es fehlen noch mehr Libraries, wie die ia32-lib. Da Du jetzt mit dem noch älteren gtkterm zufrieden bist, kannst Du die ganzen Libraries wieder los werden mit:
1 | sudo apt-get purge libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386 |
2 | sudo apt-get autoremove |
Johann D. schrieb: > Linux Mint Cinnamon 19.2 Das basiert doch auf Ubuntu und die haben doch soeben alle 32Bit Libs rausgeworfen. Valve mit Steam hat daraufhin auch den Ubuntu Support eingestellt. Also die Libs nachinstallieren, wie hier soeben getan. Oder direkt Debian nutzen anstatt als letzter in der Kette zu verhngern. (MINT -> Ubuntu -> Debian) Weobei es ja auch die Linux Mint Debian Edition gibt.
Mw E. schrieb: > Johann D. schrieb: >> Linux Mint Cinnamon 19.2 > > Das basiert doch auf Ubuntu und die haben doch soeben alle 32Bit Libs > rausgeworfen. > Valve mit Steam hat daraufhin auch den Ubuntu Support eingestellt. > Die Entscheidung wurde sofort rückgängig gemacht. Außerdem wäre das erst mit Ubuntu 19.10 gekommen.
Mario M. schrieb: > Möglicherweise hast Du ein reines 64Bit-System und es fehlen noch mehr > Libraries Ja, es fehlt nach Installation der weiter oben vorgeschlagenen i386-Pakete immer noch mindestens eine Lib: libpng12-0. Die ist so scheisse alt, dass sie schon vor Jahren nicht mehr direkt verfügbar war. Die letzte Ubuntu-Version, wo sie enthalten war, war xenial. Aber man kann sie immer noch runterladen und installieren, denn sie hat zum Glück weder Abhängigkeiten, die irgendwelche Konflikte erzeugen noch erzeugt sie selber welche. Sprich: man kann HTerm auf einem aktuellen Linux Mint immer noch verhältnismäßig einfach nativ laufen lassen. Aber warum aber ist das unter Windows doch noch so viel einfacher?
physiker schrieb: > Mw E. schrieb: >> Johann D. schrieb: >>> Linux Mint Cinnamon 19.2 >> >> Das basiert doch auf Ubuntu und die haben doch soeben alle 32Bit Libs >> rausgeworfen. >> Valve mit Steam hat daraufhin auch den Ubuntu Support eingestellt. >> > > Die Entscheidung wurde sofort rückgängig gemacht. Außerdem wäre das erst > mit Ubuntu 19.10 gekommen. Aber es ging doch gar nie um die entfernung der libs, sondern nur darum, das die bei einem release wie alles andere auch mal eingefroren werden, also keine nicht security updates mehr bekommen in dem release, wie alles andere früher oder später auch. So geht das nunmal bei nicht rolling-release distros, irgendwann läuft alles stabil, und dan ist erstmal schluss mit neuem zeug in dem release, damit das alles nicht plötzlich kaputt geht.
c-hater schrieb: > Aber warum aber ist das unter Windows doch noch so viel einfacher? Einfacher? Weil sie die ganzen Altlasten mitschleppen müssen. Wenn ich an die letzten Update-Probleme denke...... Aber mal im Ernst. Linux bringt soviele Tools mit. Man muss nicht jeden alten Mist installieren wollen, nach dem Motto "Ich benutze es schon seit so vielen Jahren, und es hat immer funktioniert....". Schu dir MacOS an. Die machen regelmässig einen sauberen Schnitt und schneiden die alten Zöpfe ab.
Wie kommt man überhaupt auf die Idee, etwas zu installieren, von dem man keinen Quellcode hat? Solchen mist sollte man gar nicht erst beachten.
DPA schrieb: > Wie kommt man überhaupt auf die Idee, etwas zu installieren, von dem man > keinen Quellcode hat? Solchen mist sollte man gar nicht erst beachten. Wie kann man estwas essen, von dem man kein Gaschromatogramm vorliegen hat?
Danke für das Interesse, nachdem ich das Zeugs wieder entfernen wollte: hans@Lati:~$ sudo apt-get purge libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386 [sudo] Passwort für hans: Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Paket »libgtk2.0-0:i386« ist nicht installiert, wird also auch nicht entfernt. Meinten Sie »libgtk2.0-0«? Paket »libsm6:i386« ist nicht installiert, wird also auch nicht entfernt. Meinten Sie »libsm6«? Paket »libstdc++6:i386« ist nicht installiert, wird also auch nicht entfernt. Meinten Sie »libstdc++6«? 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 526 nicht aktualisiert. habe ich erst gemerkt, das was schief lief und noch mal: hans@Lati:~$ sudo apt-get install libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386 um es jetzt nicht zu breit zu treten, da war dann auch noch zuerst ein apt-get update erforderlich, damit alles installiert werden konnte und nach hans@Lati:~$ hterm & [1] 6983 hans@Lati:~$ hterm: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory [1]+ Exit 127 hterm hans@Lati:~$ sudo apt-get install libpng12.so.0 Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig E: Paket libpng12.so.0 kann nicht gefunden werden. E: Mittels des Musters »libpng12.so.0« konnte kein Paket gefunden werden. E: Mittels regulärem Ausdruck »libpng12.so.0« konnte kein Paket gefunden werden. habe ich hterm mal ruhen lassen und wieder ein Versuch mit gtkterm gemacht (mit aungeschlossenem USB-Seriell-Adapter) hans@Lati:~$ gtkterm & [1] 7079 Das Fenster öffnete sich, doch gleich kam dann noch ein kleines Fenster mit der Fehlermeldung: Cannot open /dev/ttyS0: Keine Berechtigung Das mit den Berechtigungen habe ich nach vielen Jahren Linux immer noch nicht ganz intus. Auf dem Dell Latitude E6410 hier habe ich auch ein W10 drauf und darauf die Windows-Hterm-Version jetzt auch installiert. Für Wine habe ich in Mint noch PlayonLinux installiert, doch mit wine bin ich auch noch nicht klar gekommen, mit oder ohne Frontend, da bräuchte ich wieder eine genaue Anleitung. Momentan habe ich Hterm nur auf einem alten Laptop mit Win98 im Einsatz und falls das ausfallen sollte, hätte ich noch ein nicht ganz so altes Laptop mit Pentium M CPU und auf dem ist das BS Q4OS drauf und da gab es mit dem Linux-hterm wieder gar keine Probleme. Ob man Hterm verwenden oder nicht verwenden sollte, ist in diesem Forum an anderen Stellen schon so viel diskutiert worden, dafür sollte dieser Thread nicht gedacht sein. Falls noch jemand zum Thema Berechtigung oder Wine schreibt, hätte ich da auch wieder was gelernt, Gruß Hans
Johann D. schrieb: > Das Fenster öffnete sich, doch gleich kam dann noch ein kleines Fenster > mit der Fehlermeldung: > Cannot open /dev/ttyS0: Keine Berechtigung sudo usermod -a -G dialout <dein username>
Johann D. schrieb: > habe ich hterm mal ruhen lassen und wieder ein Versuch mit gtkterm > gemacht > (mit aungeschlossenem USB-Seriell-Adapter) > > hans@Lati:~$ gtkterm & > [1] 7079 > > Das Fenster öffnete sich, doch gleich kam dann noch ein kleines Fenster > mit der Fehlermeldung: > Cannot open /dev/ttyS0: Keine Berechtigung > > Das mit den Berechtigungen habe ich nach vielen Jahren Linux immer noch > nicht ganz intus. Ein USB-Seriell-Adapter sollte eigentlich als /dev/ttyUSB0 zu finden sein. ttyS0-9 sind eigentlich native Serielle Schnittstellen. Möglicherweise benutzt du also das falsche Deivce-File. Trotzdem wirst du weiterhin das Problem mit den Zugriffsrechten haben. Für einen schnellen Test kannst du hterm (oder gtkterm) mal mit sudo starten (Achtung, ganz ganz böse) und testen ob so alles läuft. Das ist aber keine Dauerlösung. Danach kannst du dir die nötigen Rechte immer noch über den deiner Distribution entsprechenden sauberen Weg beschaffen. Die Gruppe dialout ist da normalerweise der richtige Weg. Ich selbst hab hterm vor kurzem unter Arch eingesetzt. Das ging relativ problemlos, sobald man weiß dass man die 32-Bit Libs installieren muss. gtkterm (und auch sonst kein term) sind leider kein adäquater Ersatz für hterm. Das Tool hat doch einen sehr speziellen Einsatzzweck und ist in dieser Nische ein Unikat. Wenn nicht eh schon so viele Projekte liegen blieben wäre ein OSS-Nachfolger mal ein schönes Projekt :-)
:
Bearbeitet durch User
Was soll eigentlich ausgerechnet an hterm so besonders sein daß es diesen nachhaltigen Hype verdient? Da ist doch keine Raketentechnologie drin und außerdem ist es auch sonst eher mittelmäßig und noch dazu vollkommen unperformant? Sowas wie hterm hat doch ein engagierter Hobbypprogrammierer an zwei Wochenenden komplett nachgebaut, inklusive sämtlicher Features und exklusive aller nervigen Bugs! Warum ist das noch nicht geschehen oder wenn es geschehen ist (halte ich für sehr wahrscheinlich) warum wird das ignoriert?
Le X. schrieb: > gtkterm (und auch sonst kein term) sind leider kein adäquater Ersatz für > hterm. Das Tool hat doch einen sehr speziellen Einsatzzweck und ist in > dieser Nische ein Unikat. Das würde mich jetzt auch mal interessieren, was an hterm so speziell ist was man mit anderen Tools nicht auch erschlagen kann. Ich selbst verwende gtkterm oder moserial und vermisse da eigentlich nichts.
Bernd K. schrieb: > Was soll eigentlich ausgerechnet an hterm so besonders sein Andreas B. schrieb: > Das würde mich jetzt auch mal interessieren, was an hterm so speziell > ist Nun, es fängt damit an dass es, entgegen dem Namen, eben kein Terminalprogramm wie gtkterm oder putty ist sondern eher ein low-level-Analysetool für die Serielle Schnittstelle. Die Darstellung der Zeichen in hex, dez, oct und bin (wenns sein muss gleichzeitig) inklusive Zeitstempel, das Zählen von Zeichen und das freie Definieren von Zeilenenden (inklusive Timeouts) sind schon sehr praktisch, z.B. wenn man eine Verbindung oder ein Protokoll debuggt. Mir hat es sehr geholfen einen auf dem STK500-Protokoll basierenden Bootloader zu implementieren und später zu optimieren, oder einen XCP-Stack. Gerade bei Binärprotokollen kann es gut glänzen. Man kriegt das ganze sicher alles irgendwie in anderen Programmen hin, wenns sein muss sogar mit ner bash und etwas termio-magic. Man sollte aber dabei nicht vergessen dass gtkterm, putty & Co. eher einen anderen Einsatzzweck haben, nämlich Remoteverbindungen mittels telnet oder ssh. Bernd K. schrieb: > Sowas wie hterm hat doch ein engagierter Hobbypprogrammierer an zwei > Wochenenden komplett nachgebaut Ja, hätte er. Es ist sicher keine Raketenwissenschaft, hat auch niemand behauptet.
:
Bearbeitet durch User
Le X. schrieb: > Bernd K. schrieb: >> Sowas wie hterm hat doch ein engagierter Hobbypprogrammierer an zwei >> Wochenenden komplett nachgebaut > > Ja, hätte er. > Es ist sicher keine Raketenwissenschaft, hat auch niemand behauptet. Na dann, liebe hterm Freunde: Macht mal los. ;-) Im Ernst, da ist die Frage von Bernd K. schon berechtigt: wenn hterm eine solche Fan Gemeinde hat, frage ich mich auch warum sich da noch niemand drangemacht hat, das seit >10 Jahren nicht mehr gepflegte Programm mal neu aufzusetzen. Ich schätze auch daß das nicht mehr als 2 WE dauern würde.
Le X. schrieb: > Die Gruppe dialout ist da normalerweise der richtige Weg.
1 | sudo useradd -g dialout hans |
Unter Mint 19.2 muss man die libpng manuell herunterladen und installieren. http://security.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1.1_i386.deb
1 | sudo dpkg -i libpng12-0_1.2.54-1ubuntu1.1_i386.deb |
Andreas B. schrieb: > Im Ernst, da ist die Frage von Bernd K. schon berechtigt: wenn hterm > eine solche Fan Gemeinde hat, frage ich mich auch warum sich da noch > niemand drangemacht hat, das seit >10 Jahren nicht mehr gepflegte > Programm mal neu aufzusetzen. Vermutlich ausschließlich deshalb, weil der Quelltext nicht frei verfügbar ist. Wäre er das, wäre das Programm wahrscheinlich wirklich an einem oder maximal zwei Wochenenden an die Gegenwart anzupassen. > Ich schätze auch daß das nicht mehr als 2 > WE dauern würde. Solche Schätzungen kommen gewöhnlich von Leuten, die selber praktisch garnicht programmieren können. Von den typischen C&P-"Programmierern" oder gar von solchen, die nur irgendwann mal ein "Hello world" übersetzt bekommen haben und sich dadurch irgendwie als "Programmierer" fühlen... Nö, ein GUI-Programm mit einigem Funktionsumfang ist eben nicht from scratch an zwei WE zu programmieren. Allein das GUI-Design und die GUI-Logik, die in jeder beliebigen Situation den Benutzer davon abhält, irgendwelchen Mist zu bauen, ist schon recht aufwendig. Dazu kommt dann noch die eigentliche Programmfunktionalität... Jeder, der tatsächlich selber schonmal so etwas programmiert hat, würde den Aufwand für einen voll funktionalen HTerm-Nachbau eher auf mindestens zwei Arbeitswochen Vollzeit schätzen (das schliesst dann allerdings die Eleminierung diverser Schwächen von HTerm gleich ein).
Mario M. schrieb: > Unter Mint 19.2 muss man die libpng manuell herunterladen und > installieren. > http://security.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1.1_i386.deb >
1 | sudo dpkg -i libpng12-0_1.2.54-1ubuntu1.1_i386.deb |
Naja, es wurde alles schon gesagt. Nur noch nicht von jedem...
c-hater schrieb: > Nö, ein GUI-Programm mit einigem Funktionsumfang ist eben nicht from > scratch an zwei WE zu programmieren. In Assembler sicherlich nicht, da hat der c-hater sicherlich recht. > Allein das GUI-Design Ansonsten sehe ich da kein großartiges Design, das aufwendigste ist die Textarea mit der aufwendigen Darstellung, da kann man sich echt dran verkünsteln, der Rest vom Fenster ist im GUI-Designer in 20 Minunten aus ganz normalen Standardwidgets zusammengeklickt. Natürlich würden nach der Veröffentlichung nach 2 durchgecodeten Wochenenden zahlreiche Verbesserungsvorschläge und auch Bugreports von Nutzerseite kommen und es dann beliebig lange weiterentwickelt und erweitert. Aber der erste voll funktionsfähige Prototyp wäre bei einem unverheirateten Entwickler und bei schlechtem Wetter in 2WE fertig. Und zwar inklusive der hübschen bunten Textarea. Diese würde ich sogar als erstes angehen und da kann man sich am längsten dran verkünsteln und Zeit versenken, der Rest ist nämlich vollkommen triviale Pillepalle die man im Halbschlaf abwickelt, oder wo siehst Du da irgendwelche komplexe Funktionalität?
:
Bearbeitet durch User
c-hater schrieb: >> Ich schätze auch daß das nicht mehr als 2 >> WE dauern würde. > > Solche Schätzungen kommen gewöhnlich von Leuten, die selber praktisch > garnicht programmieren können. Von den typischen C&P-"Programmierern" > oder gar von solchen, die nur irgendwann mal ein "Hello world" übersetzt > bekommen haben und sich dadurch irgendwie als "Programmierer" fühlen... Nö, in Lazarus (Objectpascal) mach ich Dir das an 2 WE. Die GUI steht ja schon da, braucht also nur noch kopiert zu werden. Und die Logik dahinter ist auch kein Hexenwerk. Was vermutlich mehr Zeit beanspruchen würde, ist das Programm an die eigenen Ansprüche anzupassen. Bernd K. schrieb: > der Rest vom Fenster ist im GUI-Designer in 20 Minunten aus > ganz normalen Standardwidgets zusammengeklickt. So ist es. Auch sonst : Full Ack.
Beitrag #5945959 wurde von einem Moderator gelöscht.
Beitrag #5945961 wurde von einem Moderator gelöscht.
Beitrag #5945969 wurde von einem Moderator gelöscht.
Beitrag #5946023 wurde von einem Moderator gelöscht.
Wieder zurück zum Thema. Die vorher installierten Pakete habe ich mit sudo apt-get purge libgtk2.0-0:i386 libsm6:i386 libstdc++6:i386 sudo apt-get autoremove wieder entfernt, ohne Fehlermeldung, dafür schluckt mir die Konsole jetzt die Umlaute. hans@Lati:~$ sudo useradd -g dialout hans [sudo] Passwort fÃŒr hans: useradd: Benutzer »hans« existiert bereits hans@Lati:~$ sudo usermod -a -G dialout hans hans@Lati:~$ gtkterm & [1] 2017 Wieder das selbe wie vorher, das Fenster öffnete sich, doch gleich kam dann noch ein kleines Fenster mit der Fehlermeldung: Cannot open /dev/ttyS0: Keine Berechtigung hans@Lati:~$ sudo gtkterm & [1] 2781 Das kleine Fenster mit der Fehlermeldung kam dann nicht, obwohl in der Konsole hans@Lati:~$ Steuersignale gelesen: Eingabe-/Ausgabefehler kam. Am seriellen Anschluß war allerdings kein Endgerät. Das gtkterm habe ich mir dann mal angesehen, soweit ich bisher durchgestiegen bin, kann man damit nur ganze Files senden, aber keine einzelne Zeichen über die Tastatur rausgeben. Habe dann mal moserial installiert, Fenster geht ohne Fehlermeldung auf, Porteinsellungen ohne Handshake festgelegt und versucht ein paar Zeichen rauszuschicken: Fehler: Gerät konnte nicht geöffnet werden:/dev/ttyS0 In der Konsole kam dabei: hans@Lati:~$ moserial & [1] 3687 hans@Lati:~$ Gtk-Message: 22:41:51.781: GtkDialog mapped without a transient parent. This is discouraged. Gtk-Message: 22:43:40.640: GtkDialog mapped without a transient parent. This is discouraged. So habe ich auch noch cutecom probiert zu installieren: hans@Lati:~$ tar -xzf cutecom-0.22.0.tar.gz hans@Lati:~$ ls asem51_1.3-2_i386.deb LICENSE.TXT Bilder Musik changelog.txt Ãffentlich cutecom-0.22.0 "PlayOnLinux's virtual drives" cutecom-0.22.0.tar.gz Schreibtisch hterm.tar.gz Vorlagen hans@Lati:~$ cd cutecom-0.22.0 hans@Lati:~/cutecom-0.22.0$ ls Changelog COPYING cutecommdlg.ui qcppdialogimpl.h CMakeLists.txt cutecom.1 main.cpp README configure cutecom.desktop qcppdialogimpl.cpp TODO hans@Lati:~/cutecom-0.22.0$ Jetzt stehe ich wieder auf dem Schlauch, vermute mal, daß man da die CMakeLists.txt mit make erst selber compillieren muß. Vielleicht kann mir auch noch wer das mit wine für das Win-hterm erklären. Gruß Hans
>Jetzt stehe ich wieder auf dem Schlauch, vermute mal, daß man da die >CMakeLists.txt Ja, mach' nur, ändert halt am Problem nix. Macht mit dem Kopf gegen die Wand hämmerneigentlich Spass?
Johann D. schrieb: > Fehler: Gerät konnte nicht geöffnet werden:/dev/ttyS0 Hast du meinen Beitrag übersehen? Bei Verwendung eines USB-Seriell-Wandlers sollte das Devicefile /dev/ttyUSB0 oder ähnlich heißen. Dein /dev/ttyS0 ist mit hoher Wahrscheinlichkeit falsch. Schau mal bei dir, bei angestecktem Wandler, im Verzeichnis /dev welche tty-Files existieren. Am besten postest du die Ausgabe von
1 | cd /dev |
2 | ls -al | grep tty |
Nebenbei: Dein Problem ist dass du nicht weißt welches Device-File (unter Windows würde man sagen: welchen COM-Port) du brauchst. Und wenn du es wüsstest musst du dir erstmal die nötigen Rechte beschaffen um darauf zuzugreifen (notfalls erstmal mittels sudo). Aber diese beiden Probleme wirst du immer haben, unabhängig vom verwendeten Terminalprogramm. Daran ändert sich auch nichts wenn du noch hundert Tools installierst oder compilierst. Damit müllst du dir nur dein System zu.
:
Bearbeitet durch User
Johann D. schrieb: > So habe ich auch noch cutecom probiert zu installieren: > > hans@Lati:~$ tar -xzf cutecom-0.22.0.tar.gz Warum installierst Du es nicht ganz normal aus dem Repository?
Danach ist mir erst noch der Beitrag von Le X eingefallen und nach dem Einstellen des ttyUSB0 funktionierte gtkterm und moserial, gtkterm auch als user, vermutlich war da noch der Neustart erforderlich. Vielen Dank nochmal für die Unterstützung und damit soll es für dieses Thema genug sein, Gruß Hans
Es Spielt keine Rolle, welches Programm du nimmst. Solange du dein Berechnungsproblem nicht löst, wird keines gehen, die wollen ja alle mit dem gleichen User auf das gleiche Terminal zugreifen, natürlich mit dem selben Resultat. Du brauchst also erstmal einen crashkurs zu Linux Berechtigungen. Aber vor all dem, schaue erstmal welches tty was richtige ist. Schaue zuerst mal nach, ob /dev/ttyS0 überhaupt das richtige tty ist. Am einfachsten macht man das so: 1) USB-seriell-Adapter ausstecken 2) "dmesg -w" ausführen, eventuell ein paar mal enter drücken. Laufen lassen. 3) USB-seriell-Adapter einstecken. 4) Bei dmesg müssten ein paar Zeilen dazugekommen sein. Da müsste irgendwo was in die Richtung "[ X.XXXXXXX] usb X-X.X: Bla bla now attached to ttyBLA123". Das ttyBLA123 ist dann das richtige. 5) Das noch laufende "dmesg -w" wieder mit ctrl+c beenden In der Manpage des verwendeten Programms stehen die Optionen, und wie man ein anderes tty device verwendet. bei "man gtkterm": https://linux.die.net/man/1/gtkterm gtkterm ist das also die "-p" Option. Also ist der Aufruf in dem Beispiel dann "gtkterm -p ttyBLA123". Das ttyBLA123 entsprechend anpassen. Damit zu den Berechtigungen. Schau dir zuerst die Berechtigungen der Datei an. z.B. mit "ls -l /dev/ttyBLA123". Das sollte eine Ausgabe generieren die etwa so aussieht: "crw-rw---- 1 root dialout 4, 1 Aug 21 09:25 /dev/ttyBLA123" Das bedeutet übersetzt: c - Es ist ein character device rw- (octal 6 -> 4+2) Der Besitzer der Datei (hier root) darf lesen (r oder octal 4) und schreiben (w oder octal 2), aber nicht ausführen (x oder octal 1). rw- Jeder in der Gruppe "dialout" darf lesen und schreiben --- Alle anderen dürfen die Datei nicht nicht Lesen, Schreiben oder Ausführen Danach schaut man sich mit "id benutzername" an, welche Gruppen der Benutzer, mit dem man darauf zugreifen will, hat. Wenn man den benutzername weglässt, zeigt es den momentanen benutzer und dessen gruppen usw. an. Beispiel:
1 | $ id |
2 | uid=1000(abre2) gid=1000(abre2) groups=1000(abre2),27(sudo) |
Den Eintrag für die Hauptgruppe des Benutzers "gid=1000(abre2)" können
wir hier erstmal ignorieren, diese ist eigentlich nur bei der Gruppe,
die neue Dateien per default bekommen, relevant, und wird beim Offnen
von dateien nicht berücksichtigt.
Relevant sind hier der Benutzer "uid=1000(abre2)" und die Gruppen
"groups=1000(abre2),27(sudo)"
Die Datei gehört momentan root, ich bin aber abre2, das root lesen und
schreiben könnte hilft mir also nichts.
Die Datei gehört zur Gruppe dialout, ich bin aber nur in den abre2 und
sudo Gruppen, das Personen in der dialout Gruppe die Datei lesen und
schreiben können, nützt mir also nichts.
Bleiben noch die Berechtigungen der Anderen auf die Datei. Andere haben
keine, nützt mir also auch nichts.
Um das Problem zu lösen, muss also eine Änderung vorgenommen werden,
durch die sich die Situation so ändert, dass ich Zugriff habe. Was
könnte ich hier also vieles ändern, um das zu erreichen:
1) Ich könnte das Programm unter einem berechtigten User starten, also
hier root. z.B. "sudo -u root gtkterm -p ttyBLA123" (Root ist hier aber
speziell, da dieser Benutzer normalerweise auf jede Datei zugreifen
kann, auch wenn es nicht seine ist. Deshalb ist das in der regel nicht
empfohlen.)
2) Ich könnte meinen Benutzer der Gruppe, welcher die Datei gehört,
hinzufügen "sudo usermod -a -G dialout abre2" (Danach muss man sich neu
anmelden, damit die Änderung übernommen wird.)
3) Ich könnte den Besitzer der Datei ändern: "sudo chown abre2
/dev/ttyBLA123"
4) Ich könnte die Gruppe, welcher die Datei gehört, ändern, auf eine,
bei der ich Mitglied bin: z.B. "sudo chown :abre2" oder "sudo chown
:sudo". Ich könnte mit "addgroup" auch eine neue Gruppe anlegen.
5) Ich könnte allen Lese und Schreibrechte auf die Datei geben "sudo
chmod o+rw /dev/ttyBLA123" ("o" steht für "others", also Andere, + heist
hinzufügen, - wäre entfernen, rw ist lesen und schreiben. Benutzerrechte
wären u (wie user) und Gruppenrechte wären g (wie group)."). Alternativ
kann man auch "chmod +006 /dev/ttyBLA123" verwenden (+ = hinzufügen, - =
entfernen, kein Vorzeichen = setzen, erste Ziffer rechte des
Dateiowners/users, zweite ziffer Gruppenrechte, dritte ziffer rechte
anderer)
Hier ist noch zusätzlich zu beachten, dass Devicefiles in /dev
heutzutage normalerweise automatisch von einem device mapper (meistens
udev) erstellt und entfernt werden, und dieser bei diesen Dateien die
Owner, Guppe und Berechtigungen angibt. Eine Änderung mit "chmod" ist
also spätestens nach einem neustart oder neu Anschliessen des Geräts
wieder weg. Man muss dann den Device Mapper entsprechend Configurieren
passende berechtigungen zu vergeben, sofern möglich (bei udev erstllt
man dafür eine udev rule und lädt alle udev rules dann neu.)
Es gäbe auch noch ACLs, um zusätzlichen Benutzern und Gruppen Zugriff
auf eine Datei zu geben, ähnlich wie bei Windows. Das verwendet aber
praktisch niemand, weill es nur unnötige Komplexität schafft.
Oh, und die Benutzer und Gruppennamen sind eigentlich nur Dekoration,
damit die dumme Menschheit das Berechtigungsystem verstehen kann. Das
System selbst interessiert sich eigentlich nur für die id Nummer der
Benutzer, Gruppen, etc. In der regel merkt man davon nichts, aber wenn
man Dateien zwischen Systemen austauscht, und die Berechtigungen im
Dateisystem das man dafür nimmt sind in diesem als Nummern gespeichert,
und die Benutzerlisten und ids der Systeme nicht übereinstimmen, dann
kann es zu Problemen kommen. Oder wenn man eine Nummer als Benutzer oder
Gruppenname verwenden will, das kann auch unschön enden (auch in
nicht-dezimalen Formaten).
Edit: Sieht so aus als wäre ich mal wieder zu langsam gewesen...
Ich hab jetzt mal ein kleines Script geschrieben, um die fehlende library Problematik zu beseitigen (siehe Anhang). Verwendung ist "mkstandalone.sh /pfad/zum/program zielverzeichnis". Es geht momentan nur mit ELF Programmen und nur auf debian, man muss alle libs bereits installiert haben (das Programm muss laufen), und man muss patchelf installiert haben. Das Programm kopiert alle benötigten Libraries nach zielverzeichnis/lib, das Programm nach zielverzeichnis/rbin, erstellt ein Script in zielverzeichnis/bin um die Programme in zielverzeichnis/rbin aufzurufen, und kümmert sich um das anpassen aller library pfade. Es versucht auf debian systemen auch noch, die Lizenzinformationen zu den dazugehörigen Paketen zu kopieren. Andere Daten, die ein Programm eventuell noch braucht, werden nicht berücksichtigt. Im Idealfall sollte man danach die Programme in zielverzeichnis später auf jedem System verwenden können, ohne zusätzliche libraries installieren zu müssen.
DPA schrieb: > Ich hab jetzt mal ein kleines Script geschrieben, um die fehlende > library Problematik zu beseitigen (siehe Anhang). Verwendung ist > "mkstandalone.sh /pfad/zum/program zielverzeichnis". Es geht momentan > nur mit ELF Programmen und nur auf debian, man muss alle libs bereits > installiert haben (das Programm muss laufen), und man muss patchelf > installiert haben. Das geht aber ziemlich dramatisch am Problem des TO vorbei. Wenn er alle nötigen Libs bereits installiert hätte, würde HTerm ja einfach laufen. Dann braucht er aber dieses Script nicht mehr...
Ja schon, aber der Author des Programs, und Ersteller sowie Distributoren vergleichbarer Programme können damit zukünftig das Program einfach neu verpacken, so das es auch immer funktional bleibt und solche Probleme sich nicht wiederholen. Sofern sie über den Beitrag stolpern. Wenn der Author von Hterm in der Lizenz nicht fordern würde, dass man seine ausdrückliche Erlaubnis braucht um alternative Downloads anzubieten, könnten das hier auch andere, die die Libraries noch haben, erledigen. Dennoch kann es sicher in Zukunft auch noch einigen helfen, die ein Programm (z.B. ihre noch funktionierende Hterm Kopie) für später konservieren wollen.
Daniel A. schrieb: > Ja schon, aber der Author des Programs, und Ersteller sowie > Distributoren vergleichbarer Programme können damit zukünftig das > Program einfach neu verpacken Schonmal was von AppImage gehört? Dieses Rad ist schon so rund wie es nur geht, man muss es nicht neu erfinden. Alle anderen machen ein .deb oder ein .rpm und schreiben die Liste der Abhängigkeiten in die Metadaten, das ist noch sauberer.
:
Bearbeitet durch User
Zweck, Anwendungsgebiet und Benutzerfreundlichkeit der 3 Technologien (Packete/Repos vs. Container vs. alles mit enm Script in ein verzeichnis packen lassen) ist aber unterschiedlich.
Daniel A. schrieb: > Zweck, Anwendungsgebiet und Benutzerfreundlichkeit der 3 Technologien > (Packete/Repos vs. Container vs. alles mit enm Script in ein verzeichnis > packen lassen) ist aber unterschiedlich Ja, ich denke die Benutzerfreundlichkeit von Appimage ist (neben dem nativen Paketsystem) am höchsten. Wohlgemerkt die NUTZER-Freundlichkeit, nicht die Autorenfreundlichkeit! Die Nutzer sind nämlich in der Überzahl, denen würd ichs einfach machen wollen, nicht der einen Person die einmal(!) ein Paket packt (und spätestens beim zweiten mal ein Script fürs packen schreibt).
:
Bearbeitet durch User
Das Script habe ich jetzt nicht verwendet, weiß auch nicht, ob es nur auf org. Debian oder auch Ubuntu und Mint läuft. Da ich in den Einstellungen für das Terminal den Pfad zur Zeichenkodierung nicht gleich fand, wie schon erwähnt wurden nach der ganzen Hin- und Herinstalliererei die Umlaute nicht mehr richtig angezeigt, habe ich die alten libs und das fehlende dann auch noch manuell installiert und noch ein apt-get upgrade nachgeschickt. Bei den Umlauten hat das nichts zurück geändert, doch hterm kann ich jetzt auch öffnen: hans@Lati:~$ hterm & [1] 2567 hans@Lati:~$ Gtk-Message: 00:55:46.313: Failed to load module "gail" Gtk-Message: 00:55:46.314: Failed to load module "atk-bridge" (hterm:2567): Gtk-WARNING **: 00:55:46.329: Im Modulpfad »pixmap« konnte keine Themen-Engine gefunden werden, (hterm:2567): Gtk-WARNING **: 00:55:46.331: Im Modulpfad »adwaita« konnte keine Themen-Engine gefunden werden, . . Das kommt so an die 20mal . . (hterm:2567): Gtk-WARNING **: 00:55:46.353: Im Modulpfad »murrine« konnte keine Themen-Engine gefunden werden, (hterm:2567): Gtk-WARNING **: 00:55:46.354: Im Modulpfad »pixmap« konnte keine Themen-Engine gefunden werden, Bei den ersten paar Versuchen hat es so ungefähr 1 Minute gedauert, bis sich das hterm-Fenster öffnete, doch jetzt ist es auch ganz normal nach ca. 1 sek da und funktioniert so wie es soll. Die Zeichenkodierung habe ich wieder richten können, und auch sonst sieht es so aus als hätte das BS (und auch die Wand ;-) ) keinen größeren Schaden genommen. So hänge ich mal ans Thema gelöst an, damit das hier auch mal zum Ende kommen kann. Gruß Hans
Die Warnungen sagen eigentlich nur aus dass dir irgendwelche Gtk-Themes fehlen. Die GUI-Frameworks, auch immer so ein leidiges Thema ;-) Das kannst du eigentlich alles ignorieren. Wahrscheinlich schaut das hterm halt jetzt aus wie irgendein Sun OS aus den 90ern weil auf ein Fallback-Thema zurückgegriffen wird.
Angehängte Dateien:
-
Hterm.png
60 KB
Le X. schrieb: > Wahrscheinlich schaut das > hterm halt jetzt aus wie irgendein Sun OS aus den 90ern weil auf ein > Fallback-Thema zurückgegriffen wird. Naja ist halt das typische bevelled 3D Design. Das gab's auf vielen Systemen, ich persönlich habe es zuerst auf einem Amiga mit Workbench 2.04 gesehen. Aber wen interessiert's? Hauptsache das Tool macht seinen Job.
Johann D. schrieb: > hans@Lati:~$ cd cutecom-0.22.0 > hans@Lati:~/cutecom-0.22.0$ ls > Changelog COPYING cutecommdlg.ui qcppdialogimpl.h > CMakeLists.txt cutecom.1 main.cpp README > configure cutecom.desktop qcppdialogimpl.cpp TODO > hans@Lati:~/cutecom-0.22.0$ > > Jetzt stehe ich wieder auf dem Schlauch, vermute mal, daß man da die > CMakeLists.txt > mit make erst selber compillieren muß. Fast. Hier hilft
1 | ./configure |
2 | make |
3 | sudo make install |
Etwas spät aber es gibt HTerm mitlerweile auch für 64bit Linux, da muss nur noch libgtk2.0-0 nachinstalliert werden: http://der-hammer.info/pages/terminal.html
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.