Das ist lediglich das Defaultverhalten. SSH kann jedes beliebige Programm remote starten, die Textausgabe übers Netzwerk übertragen und lokal anzeigen - genau wie X11 für Grafikprogramme.
Wenn SSH wie X arbeiten würde, dann würde SSH zwischen dem "ls" (als Beispiel) und dem Bildschirm hängen.
Genau so ist es aber, SSH hängt zwischen "ls" (als Beispiel) und dem lokalen tty, hier der Beweis:
SSH öffnet eine Shell auf dem entfernten Rechner. Wenn SSH wie X arbeiten würde, dann würde SSH zwischen dem "ls" (als Beispiel) und dem Bildschirm hängen.
Das ist lediglich das Defaultverhalten. SSH kann jedes beliebige Programm remote starten
Wo ist aus SSH Sicht der Unterschied zwischen einer Shell und einem beliebigen anderen Programm?
Schön, dass du die Unsinnigkeit deiner Argumentation erkannt hast.
Wenn SSH wie X arbeiten würde, dann würde SSH zwischen dem "ls" (als Beispiel) und dem Bildschirm hängen.
Genau so ist es aber, SSH hängt zwischen "ls" (als Beispiel) und dem lokalen tty, hier der Beweis
Falsch. SSH öffnet ein PTY. Die lokale Ausgabe läuft über ein TTY.
Haha, ich bin hier tatsächlich unter den Ahnungslosen gelandet. Richtig, SSH öffnet ein PTY, aber auf dem Remote-System welches es mit dem tty des lokalen Systems verbindet. Damit hängt SSH zwischen dem ls-Befehl (als Beispiel) und dem lokalen tty. Dass dem so ist und deine gegenteilige Behauptung unsinnig ist, habe ich dir bereits einen Kommentar weiter oben durch harte Fakten bewiesen.
Mich wundert langsam nicht mehr, dass die Leute Probleme haben die X11-Netzwerktransparenz zu verstehen, wenn sie schon bei SSH nicht durchsteigen.
Und wenn ich aber garkein Netzwerk brauche? Dann geht der Weg nicht über SSH. Also wie bei Wayland, nicht X11.
... einfach mal überlesen. So viel Arrogranz und Selbstgefälligkeit. Mich wunder auch nichts mehr.
1. Jedes Programm, das Du per SSH remote startest, wird durch die User-Shell gestartet. Du kannst Dir natürlich /bin/ls als User-Shell einstellen, wenn Du das brauchst, ändert aber nix am SSH verhalten.
2. SSH liegt nur dann zwischen "ls" und Bildschirm, wenn Du einen Verbindung mit SSH aufbaust. Wenn SSH wie X wäre, dann würde jede Konsolenausgabe über eine SSH Verbindung läufen.
Und wenn ich aber garkein Netzwerk brauche? Dann geht der Weg nicht über SSH. Also wie bei Wayland, nicht X11.
... einfach mal überlesen. So viel Arrogranz und Selbstgefälligkeit. Mich wunder auch nichts mehr.
Weil es Unsinn ist und ich nicht jeden Unsinn kommentieren muss. Aber da du dich beleidigt fühlst, wenn man den größten Unsinn wohlwollend überliest, hier für dich zum Mitschreiben und auswendig lernen:
Lokale X11-Verbindungen gehen nicht übers Netzwerk!
1. Jedes Programm, das Du per SSH remote startest, wird durch die User-Shell gestartet. Du kannst Dir natürlich /bin/ls als User-Shell einstellen, wenn Du das brauchst, ändert aber nix am SSH verhalten.
Nichts als Unsinn. SSH ruft jedes beliebige Programm direkt auf, nicht über die Shell.
Es hat auch nichts mit der eingestellten User-Shell zu tun, was du anhand meines Einzeilers zwei Kommentare weiter oben deutlich erkennen kannst, vorausgesetzt du wärst in der Lage ihn zu erfassen.
2. SSH liegt nur dann zwischen "ls" und Bildschirm, wenn Du einen Verbindung mit SSH aufbaust. Wenn SSH wie X wäre, dann würde jede Konsolenausgabe über eine SSH Verbindung läufen.
Und erneut dieser Unsinn. Lokale X11-Verbindungen gehen nicht übers Netzwerk!
Willst Du Dich jetzt daran hochziehen, das Unix-Sockets keine Netzwerkverbindungen sind?
Richtig, sind sie nicht.
Der Unix Socket weiß, das er auf einer Machine arbeitet und umgeht das Netzwerk. Trotzdem wird er extern, also vom X-Client, wie ein Netzwerk-Socket benutzt. Das führt dazu, dass die Daten mindestens einmal kopiert werden müssen und das merkt man dem Linux Desktop doch deutlich an.
Ich merke das dem Linux-Desktop nicht deutlich an. Das mag daran liegen, weil für mich Produktivität entscheidend ist.
Das die Schnittstellen sehr ähnlich gehalten sind liegt an der UNIX-Philosophie. Deshalb sind sie nicht identisch und die Aussage des Vorredners ist und bleibt Unsinn.
Generell ist es natürlich zu begrüßen, sich Gedanken über die Interprozesskommunikation zu machen und wie diese effizient umgesetzt werden kann. Nur kann dies weder als Freibrief noch als Argumentationsgrundlage dienen, bewährte Funktionalität schlechtzureden und so zu tun als würde sie niemand nutzen, weil man sie selbst nicht nutzt.
Das ist lediglich das Defaultverhalten. SSH kann jedes beliebige Programm remote starten, die Textausgabe übers Netzwerk übertragen und lokal anzeigen - genau wie X11 für Grafikprogramme.
Genau so ist es aber, SSH hängt zwischen "ls" (als Beispiel) und dem lokalen tty, hier der Beweis:
$ ssh www-data@test.local "ls -1" | grep debian
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Feb 2012 um 01:53.debian
Wo ist aus SSH Sicht der Unterschied zwischen einer Shell und einem beliebigen anderen Programm?
Und wenn ich abver garkeine Netzwerk brauche? Dann geht der Weg nicht über SSH. Also wie bei Wayland, nicht X11.
Falsch. SSH öffnet ein PTY. Die lokale Ausgabe läuft über ein TTY.
Schön, dass du die Unsinnigkeit deiner Argumentation erkannt hast.
Haha, ich bin hier tatsächlich unter den Ahnungslosen gelandet. Richtig, SSH öffnet ein PTY, aber auf dem Remote-System welches es mit dem tty des lokalen Systems verbindet. Damit hängt SSH zwischen dem ls-Befehl (als Beispiel) und dem lokalen tty. Dass dem so ist und deine gegenteilige Behauptung unsinnig ist, habe ich dir bereits einen Kommentar weiter oben durch harte Fakten bewiesen.
Mich wundert langsam nicht mehr, dass die Leute Probleme haben die X11-Netzwerktransparenz zu verstehen, wenn sie schon bei SSH nicht durchsteigen.
... einfach mal überlesen. So viel Arrogranz und Selbstgefälligkeit. Mich wunder auch nichts mehr.
1. Jedes Programm, das Du per SSH remote startest, wird durch die User-Shell gestartet. Du kannst Dir natürlich /bin/ls als User-Shell einstellen, wenn Du das brauchst, ändert aber nix am SSH verhalten.
2. SSH liegt nur dann zwischen "ls" und Bildschirm, wenn Du einen Verbindung mit SSH aufbaust. Wenn SSH wie X wäre, dann würde jede Konsolenausgabe über eine SSH Verbindung läufen.
Aber egal, ich steig hier aus.
Weil es Unsinn ist und ich nicht jeden Unsinn kommentieren muss. Aber da du dich beleidigt fühlst, wenn man den größten Unsinn wohlwollend überliest, hier für dich zum Mitschreiben und auswendig lernen:
Lokale X11-Verbindungen gehen nicht übers Netzwerk!
Nichts als Unsinn. SSH ruft jedes beliebige Programm direkt auf, nicht über die Shell.
Es hat auch nichts mit der eingestellten User-Shell zu tun, was du anhand meines Einzeilers zwei Kommentare weiter oben deutlich erkennen kannst, vorausgesetzt du wärst in der Lage ihn zu erfassen.
Und erneut dieser Unsinn. Lokale X11-Verbindungen gehen nicht übers Netzwerk!
Das ist auch das Beste was du tun kannst.
Willst Du Dich jetzt daran hochziehen, das Unix-Sockets keine Netzwerkverbindungen sind? Bitte! Deine Meinung.
OMFG ... RTFM! Oder probiere es aus, wenn Du nicht lesen willst!
Richtig, sind sie nicht.
Meinung?? Um Meinungen ist es bei technischen Fakten noch nie gegangen.
Richtig, RTFM! Warum beherzigst du es nicht?
$ man ssh | grep "login shell"
If command is specified, it is executed on the remote host instead of a login shell.
Ich warte schon darauf, mit was du dich als nächstes lächerlich machen willst.
Hast Du es probiert?
Mach hald wenn du weder mir noch der Manpage glaubst oder dieser nicht folgen kannst. Ich weiß ja wie es funktioniert.
Tut mir ja Leid für Dich, aber klausi hat recht. Du bist nicht unfehlbar, auch wenn Du das glaubst.
Der Unix Socket weiß, das er auf einer Machine arbeitet und umgeht das Netzwerk. Trotzdem wird er extern, also vom X-Client, wie ein Netzwerk-Socket benutzt. Das führt dazu, dass die Daten mindestens einmal kopiert werden müssen und das merkt man dem Linux Desktop doch deutlich an.
Ich merke das dem Linux-Desktop nicht deutlich an. Das mag daran liegen, weil für mich Produktivität entscheidend ist.
Das die Schnittstellen sehr ähnlich gehalten sind liegt an der UNIX-Philosophie. Deshalb sind sie nicht identisch und die Aussage des Vorredners ist und bleibt Unsinn.
Generell ist es natürlich zu begrüßen, sich Gedanken über die Interprozesskommunikation zu machen und wie diese effizient umgesetzt werden kann. Nur kann dies weder als Freibrief noch als Argumentationsgrundlage dienen, bewährte Funktionalität schlechtzureden und so zu tun als würde sie niemand nutzen, weil man sie selbst nicht nutzt.