Sie sind nicht angemeldet.

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

1

23.06.2012, 14:55

[gelöst] interactive Login-Shell

Hallo zusammen,

ich habe im Grunde verstanden, dass bei ssh die Datei .bash_profile eingelesen wird. Ein Blick auf die man-page machte mich dennoch stutzig:

In der man-page von bash steht unter anderem folgendes:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists.

So, ich weiss dass ssh definitiv eine Login-Shell ist. Und das normale Terminal nach dem Einloggen(ohne ssh, sondern normal über graphische Umgebung) eine No Login Shell ist.


Das Wort "interactive" irritiert mich. Ist das normale Terminal nach dem Einloggen in ein Ubuntu-System eigentlich eine "interactive No Login Shell"? Oder welche shell ist mit "interactive login shell" gemeint?

ist ssh eine interactive Login-Shell oder eine non interactive Login-Shell? Oder sogar beides?

Vielen lieben Dank,

Eure Ratna :)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ratnalein« (27.06.2012, 23:17)


2

23.06.2012, 16:10

Hi,
Das steht eigentlich alles in den Absätzen vor und nach dem von dir zitierten Teil der man-page:

Zitat

An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals
Ist das normale Terminal nach dem Einloggen in ein Ubuntu-System eigentlich eine "interactive No Login Shell"?
Wenn sie auf deine Eingaben wartet und dann was zurückgibt, ist sie wohl "inter-aktiv" :)

Zitat

When bash is started non-interactively, to run a shell script, for example [...]
Wenn du ihr zB. ein Kommando als Parameter mitgibst, das sie abarbeitet und sich wieder beendet, kannst du eigentlich nicht mit ihr inter-agieren. Das gleiche gilt natürlich auch, wenn du ein ausführbares Shell-Script startest, das in seiner ersten Zeile eine Shell aufruft. Beides wirst du vielleicht aus einer interaktiven Shell heraus machen. Die entscheidet dann nämlich nach dieser ersten Zeile, was zu tun ist und startet darauf eine weitere shell, die den Rest abarbeitet. Sobald diese sich beendet hat, zeigt dir die interaktive das Ergebnis der nicht-interaktiven und wartet auf weitere Eingaben.
In einem GUI kann das auch durch Doppelklick passieren, dann steht da keine interaktive herum, sondern es läuft nur die non-interaktive mit dem Script durch.

ist ssh eine interactive Login-Shell oder eine non interactive Login-Shell? Oder sogar beides?
Kommt auf die Konfiguration und den Aufruf an. In der Regel wird es als interaktive Login-Shell verwendet. Ich kann ssh aber auch mit einem Kommando-, Script- oder Programmaufruf starten. Dann wird dieses nach dem Login abgearbeitet und das war's dann.
Umgekehrt kann ich auch über die Server-Konfiguration festlegen, daß nach dem Login nur etwas bestimmtes passiert und der User wieder rausfliegt. Da ist dann auch kein Platz für Inter-Aktivität. :)
SSH ist so gesehen selbst gar keine Shell, sonder nur die Verbindung zu einem anderen Rechner.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

3

23.06.2012, 17:09

putty zum Beispiel wäre also eine interactive Login-Shell. Im Internet habe ich folgendes gefunden:

There are different types of shells. The SSH command execution shell is a non-interactive shell, whereas your normal shell is either a login shell or an interactive shell. Description follows, from man bash

Putty ist doch SSH command execution shell oder? Warum sagt er dann, dass dies a non-interactive shell ist?

Danke Dir.

Schöne Grüße aus Rheinland,

Eure Ratna

4

23.06.2012, 17:30

Ohne Kontext kann man dein gefundenes Zitat natürlich schwer interpretieren oder erklären. Laut der man-page von bash wäre eine "command execution shell" eben genau das, was dort als Beispiel angeführt ist

Zitat

...to run a shell script, for example
und somit eine andere Bezeichnung für "non-interactive shell". </Erklärungsversuch off>

Als was sich Putty selbst definiert, weiß ich nicht. Ich betrachte es als Programm, das sich mit einem SSH-Server verbinden kann. Es macht auch ein Fenster auf, in dem der User die danach verbundene entfernte Shell sieht. Also ein SSH-Client mit GUI, jedenfalls selbst keine Shell.
Als ich noch unter Windows litt, habe ich natürlich auch Putty benutzt. Ich kann mich aber nicht erinnern, ob der auch one-shot Kommandos absetzen kann oder immer interaktiv ist (sofern ihn die Gegenstelle lässt, siehe oben) oder ob man dazu ein anderes tool aus der Putty-Sammlung benötigt.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

5

23.06.2012, 17:43

Ich betrachte es als Programm, das sich mit einem SSH-Server verbinden kann

Mhh... der SSH-Server ist in dem Fall das Linux-System(Ubuntu)?

6

23.06.2012, 17:49

Im Normalfall, meistens ja.
Ein Server ist ein Rechner, der einen Dienst (Service) zur Verfügung stellt. In diesem Fall eine Zugangsmöglichkeit per SSH. Welches Betriebssystem dort läuft, tut nichts zur Sache.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

7

23.06.2012, 17:58

vielen dank. Ich fasse mal zusammen:

ssh = Netzwerkprotokoll (mein Ubuntu unterstützt dieses Protokoll)
ssh sieht sich als interactive login-shell (login-shell -> shell used to login)
putty = ssh-client
Also, putty -> interactive login-shell

Mhh.. wie kann ich markieren, dass dieser Thread gelöst ist? Ich hab aus deinem Link gelesen, dass mit [gelöst] zu markiert ist, aber wo kann ich dies tun?

Viele Grüße aus Rheinland,
Eure Ratna

PS. Das gleiche gilt natürlich auch, wenn du ein ausführbares Shell-Script startest, das in seiner ersten Zeile eine Shell aufruft. Beides wirst du vielleicht aus einer interaktiven Shell heraus machen. Die entscheidet dann nämlich nach dieser ersten Zeile, was zu tun ist und startet darauf eine weitere shell, die den Rest abarbeitet.

Das heißt, das Abarbeiten von Befehlen innerhalb eines Shell-Skriptes ist non interaktiv. Richtig?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ratnalein« (23.06.2012, 18:10)


8

23.06.2012, 18:10

Kommt so ziemlich hin würde ich sagen.
Vergleiche vielleicht auch die man-page von SSH:

Zitat

ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine.
[...]
If command is specified, it is executed on the remote host instead of a login shell.

Somit würde ich ssh selbst nicht als Shell bezeichnen (auch wenn es der Name impliziert).
Der Login selbst hat ja mit einer Shell noch nichts zu tun. Weiters kommt es ja auch darauf an, welche Shell dort überhaupt läuft bzw. verfügbar ist. Davon ausgehend, daß es auch unter anderen Betriebssystemen SSH-Server geben kann, dort aber vielleicht keine bash, muss also nicht zwangsläufig die bash als "Login-Shell" auftauchen. Du beziehst dich aber auf die man-page von Bash, die eben auch als Login-Shell fungieren kann. Deshalb Vorsicht beim Einsatz der Begriffe.

Einfach den ersten Beitrag "bearbeiten" -> Präfix setzen.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

9

23.06.2012, 18:14

If command is specified, it is executed on the remote host instead of a login shell.

Mir ist das Englische nicht so mächtig, was heißt das?

Nun eine letzte Frage für heute:

Das gleiche gilt natürlich auch, wenn du ein ausführbares Shell-Script startest, das in seiner ersten Zeile eine Shell aufruft. Beides wirst du vielleicht aus einer interaktiven Shell heraus machen. Die entscheidet dann nämlich nach dieser ersten Zeile, was zu tun ist und startet darauf eine weitere shell, die den Rest abarbeitet.

Das heißt, das Abarbeiten von Befehlen innerhalb eines Shell-Skriptes ist non interaktiv?

10

23.06.2012, 19:25

If command is specified, it is executed on the remote host instead of a login shell.
Beispiel:
(Ich rede hier aber von einem normalen SSH-Client, nicht von Putty)

Quellcode

1
ssh <user@anderer-Rechner> 'ls -la'
-> Sucht sich den anderen Rechner, verbindet sich mit dessen SSH-Port, wickelt den Login ab und führt das Kommando "ls -la" aus. Ich bekomme das Listing des Verzeichnisses am entfernten Rechner zurück, in dem dieser User nach einem erfolgreichen Login landet (normalerweise sein $HOME). Die Verbindung ist beendet, der ssh-Client ebenfalls. Das ganze war nicht-interaktiv (ein Kommando, eine Antwort, Ende)

Quellcode

1
ssh <user@anderer-Rechner>
-> Mangels eines angegebenen Kommandos wird nach dem Login eine Shell aufgerufen. Mit der kann ich hin- und herplaudern, sie wartet immer wieder auf Eingaben, bis ich sie beende (oder die Verbindung beendet wird). Sie ist interaktiv. Sie wurde direkt nach dem Login aufgerufen, verhält sich also als Login-shell, das heißt sie hat auch Dateien geladen, mit denen die Shell-Umgebung definiert wird (damit sich der User wohl fühlt, denn zur Abarbeitung eines Scripts ist das nicht notwendig).

Das heißt, das Abarbeiten von Befehlen innerhalb eines Shell-Skriptes ist non interaktiv?
Ja, denn du kannst in der Regel nicht eingreifen. Außer, das Script fragt dich was, aber dann interagierst du mit diesem Script, nicht mit der Shell in der es läuft.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

11

24.06.2012, 00:52

If command is specified, it is executed on the remote host instead of a login shell.
Beispiel:
(Ich rede hier aber von einem normalen SSH-Client, nicht von Putty)

Quellcode

1
ssh <user@anderer-Rechner> 'ls -la'
-> Sucht sich den anderen Rechner, verbindet sich mit dessen SSH-Port, wickelt den Login ab und führt das Kommando "ls -la" aus. Ich bekomme das Listing des Verzeichnisses am entfernten Rechner zurück, in dem dieser User nach einem erfolgreichen Login landet (normalerweise sein $HOME). Die Verbindung ist beendet, der ssh-Client ebenfalls. Das ganze war nicht-interaktiv (ein Kommando, eine Antwort, Ende)



herzlichen Dank..

das heißt, nachdem Ausführen des Kommandos ls -la ist die Verbindung beendet? Wirklich nichts mehr? Kommt da kein Prompt mehr, der auf weitere Eingaben wartet wie beim normalen Shell?

Der Satz ist ja "If command is specified, it is executed on the remote host instead of a login shell."

Command ist specified = ja wohl = nämlich ls -la

it is executed on the remote host instead of a login shell = am Rechner des SSH-Hosts wird dieses Kommando ausgeführt anstatt in der login shell?

Ist das nicht immer so? Ist das nicht so, dass alle Kommandos am Rechner des SSH-Hosts ausgeführt werden? Der Satz "instead of a login shell" macht mich stutzig. Könntest Du mir vielleicht ein Beispiel geben, wo ein Kommando in der login shell ausgeführt wird?

Schöne Grüße aus Rheinland,

Eure Ratna :)

12

24.06.2012, 01:13

Die Betonung des Satzes liegt auf "it is executed" und der Rest steht für "anstatt einer Login-Shell". Beides passiert auf dem remote-host.
Also, wenn ein Kommando angegeben ist, wird dieses ausgeführt anstatt den User in eine Shell zu werfen.
Und ja, sobald das Kommando abgearbeitet ist, geht das Licht aus. Mein Beispiel war schon aus dem richtigen Leben gegriffen. :)
Es ist genau gleiche, wenn du (ohne Kommando) in der interaktiven shell landest und diese irgendwann (korrekt) beendest. Also nicht durch Schließen von Putty, denn da wird nur die Verbindung unterbrochen. Das wäre auch ein Beispiel für ein Kommando in dieser shell:

Quellcode

1
exit
Was macht jetzt die Verbindung?
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

13

24.06.2012, 10:55

vielen herzlichen Dank für die ausführliche Erklärung. Ich habe verstanden und habe mich daraufhin weiter mit dem thema beschäftigt und bin auf etwas interessantes gestoßen. In einer Konfigurationsdatei(zum Setzen von Umgebungsvariablen zum Beispiel) sind Befehle zum Ausführen von Shellskripts. Im Fall einer Datenbankenanwendung beispielsweise:


if [ -f /home/db2inst1/sqllib/db2profile ]; then
. /home/db2inst1/sqllib/db2profile
fi


Ich habe mitbekommen, dass der Punkt davor in der 2. Zeile bewirkt, dass das Skript db2profile doch bitte nicht in einer extra zu erzeugenden Subshell ausgeführt werden soll. Stattdessen bitte in der ausführenden Shell. Ich frage mich, warum soll dieser Punkt mit Leerzeichen sein?

Meine Recherche: Damit die Veränderungen der Variablen in der ausführenden Shell "wirksam" sind. Würde ich das Skript db2profile ohne Punkt davor ausführe und somit dazu eine Subshell erzeugt wird, wären die Veränderungen/Aktualisierungen lediglich in der Subshell "wirksam". Beendet sich diese Subshell, sind die Veränderungen auch weg.

Soweit so gut.

Meine Frage geht in eine andere Richtung:

Warum funktioniert in dem Fall das Ausführen des Skriptes, obwohl der User eigentlich kein Ausführrecht hat? Ich habe gesehen, dass der User eigentlich nur Leserecht hat. Dient der Punkt davor auch, um das Verbot des Ausführens umzugehen?

Schöne Grüße aus Rheinland,

Eure Ratna :P

14

24.06.2012, 17:28

Dient der Punkt davor auch, um das Verbot des Ausführens umzugehen?
Wäre ja noch schöner, gebt mir einen Punkt und ich hebe das System aus den Angeln :)
Nein, der Punkt ist eine Abkürzung für das Shell-Kommando "source" -> 'help .' bzw. 'help source'
Er bedeutet nicht mehr, als daß die angegebene Datei an dieser Stelle reingeladen wird. Da können u.a. einfach Variablendefinitionen drin stehen oder auch weitere Shell-Kommandos. In dem Fall werden diese nachgeladenen Zeilen eben an dieser Stelle ebenfalls ausgeführt. Deshalb ist es unerheblich, ob diese Datei für den User ausführbar ist. Sie muss gar nicht selbst lauffähig sein. Sie muss allerdings für den, der das Script ausführt zumindest lesbar sein.

Damit hat auch das Leerzeichen nach dem Punkt seine Berechtigung: Es trennt das Kommando ('.' bzw. 'source') vom nachfolgenden Parameter (dem Dateipfad). Wäre es nicht da, dann stünde nur eine Pfadangabe (vom aktuellen Verzeichnis ausgehend) dort, was für sich alleine nur einen Syntaxfehler bewirken würde. Außer, wenn diese Datei tatsächlich ausführbar wäre, aber dann würde sie -wie Du richtig sagst- in einer Subshell laufen (wahrscheinlich aber eher gar nicht gefunden werden...).

Irgendwo hast Du mit deiner ersten Vermutung aber nicht Unrecht: wenn man nicht aufpasst, kann man damit tatsächlich einem User mehr Power in die Hand geben als ihm zusteht. Allerdings ist das nicht die eigentliche Intention des alleinstehenden Pünktchens.
mir is wurscht

  • »ratnalein« ist der Autor dieses Themas

Beiträge: 140

Registrierungsdatum: 19.05.2012

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

  • Nachricht senden

15

25.06.2012, 10:18

Hallo Fredl,

herzlichen Dank. Sehr verständlich erklärt.

Er bedeutet nicht mehr, als daß die angegebene Datei an dieser Stelle reingeladen wird. Da können u.a. einfach Variablendefinitionen drin stehen oder auch weitere Shell-Kommandos. In dem Fall werden diese nachgeladenen Zeilen eben an dieser Stelle ebenfalls ausgeführt. Deshalb ist es unerheblich, ob diese Datei für den User ausführbar ist. Sie muss gar nicht selbst lauffähig sein. Sie muss allerdings für den, der das Script ausführt zumindest lesbar sein.

Das Pünktlchen bedeutet also, der Inhalt des Skriptes an der Stelle reingeladen wird. Soweit so gut. Aber ob dieser Inhalt vom User abgearbeitet werden darf, das ist eine andere Sache. Richtig?

Also, ich darf also sagen, source bzw. Pünktchen ist wie copy/paste?

Vielen Dank,

Eure Ratna ;)


16

25.06.2012, 20:36

ob dieser Inhalt vom User abgearbeitet werden darf, das ist eine andere Sache
Wenn er das ursprüngliche Script starten konnte und dieses (also in dem Fall mit seinen User-Rechten) die nachgeladene Datei ebenfalls lesen darf, dann darf es dessen Inhalt auch abarbeiten. Also ja, es hat mit der Ausführbarkeit des nachgeladenen Scripts nicht direkt etwas zu tun. Es müssen nur zwei Bedingungen erfüllt sein: Er muss das Script ausführen dürfen und Lesezugriff auf die zweite Datei haben.
Natürlich könnten darin dann auch Kommandos stehen, die er vielleicht nicht nutzen kann/darf. Aber da wird das Thema dann unerschöpflich...

source bzw. Pünktchen ist wie copy/paste
So ähnlich. Eigentlich mehr "read", wie es der Editor vim zB. kann. Also einfach da, wo der Cursor steht, eine andere Datei einfügen. Im Script-Ablauf wird die dann einfach Teil des Scripts.
mir is wurscht