Aufruf eines Shell-Skripts mit SSH-Exec-Kanal, aber ignoriert Aufrufe anderer Shell-Skripts

Question

Ich bin in der Lage, ein Shell-Skript auf einem Remote-Server mithilfe von JSch exec mithilfe der hier bereitgestellten hilfreiche Beispiele auszuführen. Ich kann sehen, dass die Echos vom Skript zurückgegeben werden und der Beendigungsstatus am Ende ist 0 - alles sieht auf den ersten Blick gut aus.

Das Problem besteht jedoch darin, dass das Skript selbst zu anderen Skripten aufruft, und diese scheinen vollständig ignoriert zu werden, einfach übersprungen.

Das Skript ruft andere Skripte direkt auf. d. h. die erste Zeile des Skripts ist etwas wie:

script_two.sh 

Könnte jemand irgendeinen Weg empfehlen, dies zu überwinden? Ich habe begonnen, in den "Shell" -Kanal statt "exec" zu schauen, aber das kann in meinem Fall schwierig sein, denn bevor dem Benutzer Zugang zum System gegeben wird, präsentiert der Server ein Formular zum Ausfüllen (Name, Nummer, warum sind Sie melden sich an, etc) - Ich war noch nicht in der Lage, dieses Formular programmatisch auszufüllen und zu senden, also würde ich gerne bei exec bleiben, wenn möglich.

Ich bin neu in all dem, also jede Hilfe/Beratung wäre sehr willkommen!

Code-Schnipsel unten. Wie gesagt, das scheint zu funktionieren, aber das sh-Skript, das durch "scriptFileName" im Code repräsentiert wird, ruft andere sh-Skripte auf, die nicht ausgeführt werden.

Vielen Dank im Voraus für jede Hilfe, J

JSch jsch = new JSch(); 
JSch.setConfig(FileTransferConstants.STRICT_HOST_KEY_CHECKING, "no"); 

Session session = jsch.getSession(username, hostIPAddress, port); 
session.setPassword(password); 
session.connect(); 

//create the execution channel over the session 
ChannelExec channelExec = (ChannelExec)session.openChannel("exec"); 

channelExec.setCommand(scriptFileName); 
channelExec.connect(); 

Answer 1

Ich gehe davon aus dem Skript wie folgt aussieht:

script_one.sh 
script_two.sh 

D.h. Das Skript basiert auf . (der aktuelle Pfad) in der Umgebungsvariablen PATH, was kein Standardwert ist.

Damit das Skript überhaupt funktioniert, muss die . zu der PATH in einem Startskript hinzugefügt werden. Es ist ziemlich wahrscheinlich, dass das Hinzufügen (wahrscheinlich unbeabsichtigt falsch) nur für interaktive Sitzungen auftritt. Wahrscheinlich, weil das Hinzufügen in einem Startskript erfolgt, das nur für die interaktiven Sitzungen ausgeführt wird.

Der "exec" -Kanal in der JSch (zu Recht) weist kein Pseudo-Terminal (PTY) für die Sitzung zu. Als Konsequenz wird (möglicherweise) eine andere Reihe von Startup-Skripten bezogen, als wenn Sie sich mit einem SSH-Client anmelden. Und/oder verschiedene Verzweigungen in den Skripten werden basierend auf der Abwesenheit/Anwesenheit der Umgebungsvariablen genommen. Die Umgebung unterscheidet sich möglicherweise von der interaktiven Sitzung, die Sie mit Ihrem SSH-Client verwenden.

---

Lösungen sind (in bevorzugter Reihenfolge):

• Correct das Skript nicht auf Nicht-Standardeinstellung verlassen, um die . in PATH zu haben. Rufen Sie die Unter Skripte mit einem expliziten Pfad:

  ./script_one.sh 
  ./script_two.sh 
  

• Korrigieren Sie die Startskripts die . zum PATH bedingungslos (auch für nicht-interaktive Sitzungen) hinzuzufügen.

• (nicht empfohlen) für die Pseudo-Anschlussbelegung Erzwingen des „exec“ Kanal der .setPty Methode:

  Channel channel=session.openChannel("exec"); 
  ((ChannelExec)channel).setPty(true); 
  

  Mit dem Pseudo-Terminal eine Befehlsausführung automatisieren können Ihnen böse Nebenwirkungen bringen. Siehe zum Beispiel Is there a simple way to get rid of junk values that come when you SSH using Python's Paramiko library and fetch output from CLI of a remote machine?

---

Siehe auch eine damit verbundene Frage Shell ping command with source option is failing when executed using JSch setCommand.