[Gelöst] Shell()-Befehl unter Linux und bsync-Parameter

[herz4]

Ich danke Dir abermals gogo.

"-e" war der richtige Schalter, so wartet das Terminalfenster auf eine Eingabe. Bei "-c" erscheint es gar nicht oder aber ist schneller wieder zu und weg, als ich es sah

Im Terminalfenster erscheint nur der (gewöhnliche) Prompt.

[herz4]

Noch immer funzt - bei mir - der bsync-Parameter des shell-Befehls nicht, Und endlich habe ich gogos Anregung umgesetzt, und mir Ersatz verschafft, der um ein unnötiges Warten per (ausgespieltem) Wait-Befehl herumkommt. Meine Lösung ist ein Tool, mit dem ich Bash/Systembefehle generell verbaue, mit Warten-Schalter, oder auch ohne:

Code: Alles auswählen

Function TERMINATOR (BEFEHLSFOLGE AS String, Optional WARTEN)
'20220212 

AN = "/tmp/LO_BASICSCRIPT_ARBEITET_" & Time

If Not IsMissing(WARTEN) Then
	BEFEHLSFOLGE = "touch " + AN + "; " + BEFEHLSFOLGE + "; rm -f " + AN
EndIf

shell("gnome-terminal", 1, "-- /bin/bash -c '" + BEFEHLSFOLGE + "'", True)

Do While FileExists(AN)
Wait 100
Loop

End Function

Mein tmp-Verzeichnis liegt auf einer RAM-Disk. Wait 100, also 0,1s scheint mir ein guter Kompromiss zwischen "unendlich" vielen Schleifendurchläufen mit kleinerer Zahl und dem Anspruch, "schnell" weiter gehen zu können.

Vielleicht kann der eine oder andere mein Script nutzen, ich freute mich besonders über Verbesserungsvorschläge.

[gogo]

ich sagte Dir doch, Du sollst die gesamte Codezeile des Makros posten...
Ein einzelner Befehl verhält sich exakt so wie Du das erwartest:

Code: Alles auswählen

sub TEST_BASICALLY
a = time
b= shell("konsole",1,"-e sleep 5", true)
print a , b , time
end sub

"BEFEHLSFOLGE" legt aber nahe, dass es verschiedene Befehle sind, und die werden in einem Terminalemulator parallel gestartet.

Code: Alles auswählen

sub TEST_RUBBISH
a = time
b= shell("konsole",1,"-e 'date & sleep 1 & date & sleep 1 & date & sleep 1 & date & sleep 1'", true)
print a , b , time
end sub

Das kannst Du am leichtesten vermeiden, wenn Du alle Befehlen in ein Script packst und dieses per -e an das Terminal übergibst. Dann wirst Du auch das gewünschte Ergebnis haben(kopiere myscript in Dein Home-Verzeichnis):

Code: Alles auswählen

sub TEST_SHELL
a = time
b= shell("konsole",1,"-e /home/$USER/myscript", true)
print a , b , time
end sub

Wenn Du das Script (myscript) dynamisch erstellen musst, ist zu bedenken, dass die shell-Funktion die Parameter IMMER bei Leerzeichen trennt, und bash die Parameter nochmals per IFS trennt...
Falls Du also (was in der Regel notwendig ist) Leerzeichen innerhalb einer Befehlszeile hast, musst Du diese kaschieren und danach im Script (write_bash) wieder auflösen:

Code: Alles auswählen

sub TEST_SHELL_SCRIPT
dummy = shell("/home/$USER/write_bash",1,"date#&&#sleep#1#&&#date#&&#sleep#1#&&#date#&&#sleep#1#&&#date#&&#sleep#1 echo#FERTIG sleep#5")
a = time
' consider using '--hold'!
b = shell("konsole",1,"-e /tmp/myscript", true)
print a , b , time
end sub

(Alternativ geht's auch mit Open "/tmp/myscript" ... write xyz ... da musst Du aber zum Schluss die " aus jeder Zeile am Anfang und am Ende entfernen ... per sed am einfachsten)

[herz4]

Hallo gogo,
ich danke Dir für Dein Verständnis und Deine prompte Antwort.

ich sagte Dir doch, Du sollst die gesamte Codezeile des Makros posten...

Welches der vielen hättest Du denn gern? Bsp.: echo hello; sleep 2; echo hello2; sleep 2

Ein einzelner Befehl verhält sich exakt so wie Du das erwartest:

Nein, leider nicht. Egal ob ein "einfacher" Bash-Befehl oder eine Folge wie im obigen Beispiel, der bSync-Parameter hat auf meinem System - keine - Auswirkung!
Die Anwendung "konsole" habe ich extra bei mir installiert. Trotzdem wird bei Deinem "TEST_BASICALLY" zweimal der exakt gleiche Zeitpunkt(!) getrennt von Leerzeichen, 0, Leerzeichen ausgegeben.

"BEFEHLSFOLGE" legt aber nahe, dass es verschiedene Befehle sind, und die werden in einem Terminalemulator parallel gestartet.

Mit BEFEHLSFOLGE meine ich BEFEHL[; BEFEHL2][; BEFEHL3]... usw. Ein Befehl kann dabei auch das Aufrufen eines Bash-Scripts sein.
Einzig Dein vorgeschlagenes Kopieren der Befehlsfolge in eine ("dummy"-)myscript-Datei habe ich nicht noch gesondert probiert, weil ich - damit - nicht die Hoffnung verbinde, das bSync bei mir funzt.

ist zu bedenken, dass die shell-Funktion die Parameter IMMER bei Leerzeichen trennt, und bash die Parameter nochmals per IFS trennt...

Du siehst in meinem Code, dass ich die starke Quotierung(?) mit einfachen Anführungsstrichen gewählt habe. Bis jetzt funzt mein (Tool-)Makro ohne Beanstandungen. Demzufolge entfallen für mich auch etwaige Kaschierungen oder ähnlich ...

Nochmals danke ich, nichts für ungut!

P.S. Was macht "konsole" besser oder anders als "gnome-terminal", was bei meinem System wohl standardmäßig installiert wird? (Ich wollte sonst nämlich "konsole" wieder löschen ...)

[gogo]

konsole ist der Standard-Terminal-Emulator für xterm unter KDE - irgendwo liegt bei mir auch ein Gnome rum - wenn's passt probier ich's dort mal.
Statt konsole kannst Du auch xterm verwenden, mit dem Parameter -hold bleibt das Fenster immer offen bis es durch den WM beendet wird:

Screenshot_20220212_213825.png (24.94 KiB) 4529 mal betrachtet

Screenshot_20220212_213853.png (7.61 KiB) 4529 mal betrachtet

[gogo]

btw: kannst Du erläutern was

Code: Alles auswählen

-- /bin/bash 

bewirken soll?

[herz4]

Abermals danke ich für Deine Antworten - und Frage, gogo.
Um Letztere überhaupt (annähernd) beantworten zu können, musste ich "Experimente" durchführen. So benutzte ich (erneut) alle möglichen Schalter und Schalterkombinationen von "gnome-terminal", um so eine Befehlsfolge meiner Bauart, eigentlich ein verkapptes Bash-Script ohne dieses selbst, dem Terminal zu übergeben. Und dabei stoße ich wahrscheinlich an die von Dir erklärten Grenzen, dass jedes Leerzeichen, sei es auch nur zur Trennung von Befehl und Parametern, die Folge abbrechen lässt. Somit kann ich nicht einmal einen Bashbefehl wie etwa "sleep 2" übergeben, immer "rotes" Terminal!
Und genau das lässt aber /bin/bash mit dem Schalter -c zu, wenn man die Folge - insgesamt - mit dem einfachen Anführungsstrich umschließt (wie Strings in Bash-Scripten). Also, was bei Dir das Bashscript-Dummy tut, tut für mich der Befehl bash. "-- /bin/bash" folgt der Syntax von gnome-terminal.
In meiner eigenen Erklärung hier ist unlogisch, dass "--" selbst vom Leerzeichen gefolgt ist, auch zwischen "/bin/bash" und "-c" ist ein solches, noch eins danach. Spätestens hier endet mein "Latein".
Deine Nachfrage, gogo, ließ mich gleich noch meinem "Terminator"-Tool ein "Bashinator" hinzugesellen, denn oft sind gar keine Ein- und Ausgaben, Passwörter etc. in den Befehlsfolgen nötig. Reicht, wenn es im Hintergrund abgearbeitet wird. Einziger Unterschied zwischen beiden Tools ist dann nur die shell-Zeile:

Code: Alles auswählen

shell("bash", 1, " -c '" + BEFEHLSFOLGE + "'", true)

In aller Bescheidenheit: Das englischsprachige LO-Forum macht mich glauben, dass ich kein Exot bin mit dem bSync-Problem, weshalb das "true" hier oberhalb - bei mir - rein akademisch ist
(Nach meiner Erinnerung tritt es nicht in Windoof-Systemen auf, in welchen Linuxen nicht, weiß ich nicht.)

[gogo]

versuch' einfach mal xterm (sollte vorinstalliert sein) mit dem -hold Parameter. konsole, gnome-terminal, kitty, tilda, yakuake und so wie sie alle heißen sind alles aufgemotze Versionen.

Der Grund, warum ich das Thema weiter verfolge ist, dass wild gewordene shell-Befehle zu ziemlich großen Problemen führen können. Du solltest jeden Bash-Befehl und insbesondere skripte in seiner Ausführung kontrollieren, sonst laufen die stderr nach /dev/null und dafür sind Fehlermeldungen nicht gemacht.

Die shell()-Funktion ruft EIN Programm (Parameter 1) auf und übergibt ALLE unter Parameter 3 gelisteten Optionen. Terminals und /bin/bash sind Prozessstarter innerhalb der shell()-Funktion. Sie verarbeiten ALLES, was man ihnen hinter -e/-c an Parametern übergibt, aber Dein Einfluss darauf ist "begrenzt", weil shell() davon gar nichts mitbekommt. Daher auch die vielen Probleme. Wenn da irgendetwas nicht ausführbares steht, dann kommt eine interne Fehlermeldung für Prozess xyz und das Terminal macht mit dem nächsten weiter. Die shell()-Funktion bietet daher KEINE Terminalfunktion, sondern "... ruft EIN Programm (Parameter 1) auf und übergibt ALLE unter Parameter 3 gelisteten Optionen."
usw.

Daher: Alles, was KEIN Einzelbefehl ist, MUSS, damit es richtig abläuft, über ein externes Script ausgeführt werden (welches eine Befehlskette zu einem Einzelbefehl vereinigt). Mehrere Bash-Befehle in einer shell()-Funktion abzuarbeiten kann klarerweise funktionieren, aber dafür ist sie nicht programmiert, daher sind bei Befehlsketten bSync-Probleme zwar Probleme, aber hausgemachte und kein Bug

[herz4]

Ganz großen Dank, Dir gogo, für Deine Ausdauer mit mir Langsammerker
Also, ich habe (nach meiner Erinnerung) den bSync-Parameter der shell()-Funktion erstmalig - nützlich - eingesetzt. Und zwar mit ganz elementaren Bash-Befehlen, wie z.B. sleep (Bsp. shell("sleep", 1, "3", true) lieferte mir dann tatsächlich die 3s Zeitdifferenz. Und vor allem das print-Fenster erst, als das Terminalfenster schloss. Das funzt auch mit shell("bash",1,"-c /tmp/myscript.sh", true). Soweit so gut!
Aber, mit ssh- und sshfs-Befehlen und dann notwendigerweise mehreren Parametern versagt shell - gänzlich. Der Befehl wird nicht mehr (ordentlich), mutmaßlich gar nicht ausgeführt. Da half weder shell("ssh", 1, "Parameter ...", true) direkt, noch shell("bash",1,"-c ssh Parameter ... ", true). Nada, niente. Es kommt noch besser!
shell("gnome-terminal",1,"sleep 3", true) lief zwar tadellos, stoppte aber nicht, keine Zeitdifferenz! Gleiches bei Bashscript.
shell("konsole",1,"sleep 3", true) lief tadellos, stoppte und lieferte die korrekte Zeitdifferenz, auch mit Bashscript.
Mithin habe ich jetzt den Vorteil von "konsole" selbst erfahren! ("xterm" ist hier auch nicht standardmäßig inst.) Aber auch "konsole" kommt nicht mit mehreren Parametern bei ssh oder sshfs klar.
Danke, gogo, ich bin ein gehöriges Stück weiter gekommen - gedanklich.
(Ich markier mal als gelöst.)