dongxi
Anmeldungsdatum: 23. August 2006
Beiträge: 409
Wohnort: zuhause
|
Hallo allerseits. Ich versuche soeben, mein erstes Script zu generieren... Folgendes soll es machen: zunächst soll qsynth gestartet werden, wenn dies erfolgt ist möchte ich aconnect starten Bis hierhin bin ich gekommen:
|
#!/bin/bash
# zuerst qsynth starten
qsynth
&&
# direkt aconnect? Stimmen die ports?
aconnect 24:0 128:0
|
qsynth öffnet sich auch, aber dann geht es anscheinend nicht weiter...
Ich kann auch nach öffnen von qsynth keine weiteren Befehle eingeben, weil ja eben ein Prozess ausgeführt wird. Wo ist denn da mein Fehler?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Der Shebang, wenn das kein Übertagungsfehler ist, gehört in Zeile 1 nicht 2. Wozu ist das && in Zeile 8 gedacht? Kommt mir merkwürdig vor, aber in der Shell begegnen mir auch immer wieder Sachen, die ich noch nicht kenne.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
dongxi schrieb: | #!/bin/bash
qsynth &
aconnect 24:0 128:0
exit 0
|
Jetzt würde qsynth gestartet und im Hindergrund weiterlaufen und unmittelbar aconnect gestartet werden. Ein Problem wird sein, wenn qsynth erst etwas vorbereitendes für acconect durchführen soll und wenn das etwas Zeit benötigt.Dann müsstest Du noch einen sleep dazwischen basteln. Aber nicht vergessen... das wird wohl funktionieren, aber es ist dennoch nur ein sehr einfaches Anfangs-Konstrukt ... zum Lernen.
|
dongxi
(Themenstarter)
Anmeldungsdatum: 23. August 2006
Beiträge: 409
Wohnort: zuhause
|
Also, das mit der leeren ersten Zeile ist wohl ein "verrutscher", habe ich eben nachgeschaut. Das && war so gedacht: Mit Hilfe von zwei Kaufmanns-Und && wird eine kurzschließende UND-Verknüpfung zwischen Befehlen erstellt. Dies bedeutet, dass der zweite Befehl nur ausgeführt wird, wenn der erste Befehl erfolgreich (fehlerfrei) ausgeführt wurde. Sollte es also nicht in einer eigenen Zeile stehen? Wie gesagt, ich bin an meinem ersten Skript
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Sollte es also nicht in einer eigenen Zeile stehen?
Ja, wenn sicher gestellt ist, dass qsynth auch sofort wieder MIT exit 0 zurückkehrt und nicht irgendwo hängenbleibt oder wegen eines Syntaxfehler abgeschmiert ist.
Du kannst im Terminal die Rückgabe von qsynth prüfen und feststellen obs wirklich sofort zurückkehrt.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
dongxi schrieb: Also, das mit der leeren ersten Zeile ist wohl ein "verrutscher", habe ich eben nachgeschaut. Das && war so gedacht: Mit Hilfe von zwei Kaufmanns-Und && wird eine kurzschließende UND-Verknüpfung zwischen Befehlen erstellt. Dies bedeutet, dass der zweite Befehl nur ausgeführt wird, wenn der erste Befehl erfolgreich (fehlerfrei) ausgeführt wurde. Sollte es also nicht in einer eigenen Zeile stehen? Wie gesagt, ich bin an meinem ersten Skript
Nein, es muss in einer gemeinsamen Zeile stehen: | qsynth && aconnect 24:0 128:0
|
Ein Befehl kann unterschiedlich beendet werden, eine Möglichkeit hat TomLu gezeigt, mit einfachem & um den Prozess in den Hintergrund zu schicken, d.h. er wird gestartet, aber das Programm läuft weiter ohne auf dessen Ende zu warten, oder mit einem Semikolon oder einem Zeilenumbruch. Sofort zurückkehren, wie TomLu schrieb, muss das Programm nicht. Es kann bis 2019 warten oder bis der Flughafen Berlin fertig ist, und wenn es fehlerfrei zurückkehrt aconnect aufrufen, ohne dass ich weiß, welche Parameter aconnect erwartet.
von TomLu solltest Du Dir auch nicht abschauen, das ist Humbug.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
user_unknown schrieb: von TomLu solltest Du Dir auch nicht abschauen, das ist Humbug.
Das ist mal wieder so ein typisches Statement, was mit maßloser Überheblichkeit etwas bewertet, ohne auch nur den Ansatz einer Erklärung dazu zu liefern. Dann mach Dich mal über die Wirkungsweise von Scripte unter systemd vertraut, wenn sie bei erfolgreichem Ende nicht mit 0 zurückkehren und was exit 0 im Zusammenhang mit && bedeutet. Würdest Du das wissen, hättest Du auf diese Aussage verzichtet.... es sei denn... ...si tacuisses, philosophus mansisses
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
TomLu schrieb: user_unknown schrieb: von TomLu solltest Du Dir auch nicht abschauen, das ist Humbug.
Das ist mal wieder
Mal wieder?
so ein typisches Statement,
Typisch für mich?
was mit maßloser Überheblichkeit etwas bewertet,
Nein, mit mäßiger Überheblichkeit - da würde ich mitgehen.
ohne auch nur den Ansatz einer Erklärung dazu zu liefern.
Ich bin es einfach müde. Du findest hier bestimmt 20 Erklärungen von mir dazu.
Dann mach Dich mal über die Wirkungsweise von Scripte unter systemd vertraut, wenn sie bei erfolgreichem Ende nicht mit 0 zurückkehren.
Womit kehrt denn ein Skript zurück, wenn es kein explizites "exit 0" als letztes Statement enthält?
Würdest Du das wissen, hättest Du auf diese Aussage verzichtet.... es sei denn... ...si tacuisses, philosophus mansisses
Na zum Glück habe ich meinen Asterix gelesen. Falls aconnect einen Fehlercode ausgibt würde ein Programm ohne "exit 0" diesen Fehler zurückgeben, Deine Version dagegen würde den Fehler verheimlichen. Ein fehlerfreie gelaufenes Script gibt ohnehin 0 als Fehlercode zurück.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53593
Wohnort: Berlin
|
user_unknown schrieb: Es kann bis 2019 warten oder bis der Flughafen Berlin fertig ist
Der ist fertig, wurde 1948 eröffnet. 😈
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
user_unknown schrieb: Ein fehlerfreie gelaufenes Script gibt ohnehin 0 als Fehlercode zurück.
Besser gesagt: Ein Programm gibt das Ergebnis des letzten Ausdrucks zurück. Wenn es bei vorhergehenden Fehlern nicht abbricht, dann also, obwohl nicht fehlerfrei gelaufen, 0, wenn der letzte Aufruf eine 0 zurückliefert und man nicht ausdrücklich etwas anderes veranlasst.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
user_unknown schrieb: Falls aconnect einen Fehlercode ausgibt würde ein Programm ohne "exit 0" diesen Fehler zurückgeben, Deine Version dagegen würde den Fehler verheimlichen. Ein fehlerfreie gelaufenes Script gibt ohnehin 0 als Fehlercode zurück.
Sorry.. nimms mir nicht übel, aber eine Diskussion mit Dir bleibt unergiebig und ist somit sinnlos, weil Du ja offensichtlich noch nicht mal das Problem verstanden hast: dongxi schrieb: qsynth öffnet sich auch, aber dann geht es anscheinend nicht weiter...
Das Nachdenken darüber, ob aconnect einen Fehler zurückgeben würde, ist also völlig irrelevant, weils ja noch nicht mal ausgeführt wird. Und ob er einen solchen theoretischen Fehler auswerten will, hat er gar nicht gesagt.... vermutlich deshalb nicht, weil ihm eine solche Möglichkeit gar nicht bewusst ist. Das abschließenden "exit 0" war also nur ein Hinweis darauf, dass er sich mit der Bedeutung befassen muss. Aber für tiefergehende Betrachtungen muss man natürlich das gelesene zuerst auch verstehen... wobei Dein Schreibstil eher auf Konfliktsuche hindeutet. Aber weil Du Dich ja ohnhin wohl für den großen Schlaumeier hälst, dann löse bitte auch die Baustelle hier... ich bin raus. Dir ein frohes neues und (offensichtlich dringend notwendig) entspanntes Jahr 2019.
|
dongxi
(Themenstarter)
Anmeldungsdatum: 23. August 2006
Beiträge: 409
Wohnort: zuhause
|
Nunja, ein gutes neues Jahr allerseits 😉 Mein Problem (außer daß ich keine Ahnung habe) scheint folgendes zu sein: Wenn ich aconnect mit gui nutze, dann ist zu sehen, daß ein Port dazukommt, wenn qsynth gestartet ist.
aconnect kann diesen Port also erst ansteuern, wenn qsynth vollständig läuft. Vorher passiert einfach nichts, weil der Port nicht vorhanden ist.
|
Seebär
Anmeldungsdatum: 2. Mai 2009
Beiträge: 829
|
@ TomLu: das mag dir jetzt nicht gefallen, aber ein generelles am Ende eines Scriptes ist recht sinnfrei. Um es vorsichtig zu formulieren. Da hilft auch dein Hinweis auf systemd nicht, zumal auch das hier nicht gefragt war. Die Begründung wude ja geliefert (kaschieren des letzten/vorherigen Exitcodes). Wenn einem der Exitcode wichtig ist (ist hier wohl nicht so), dann muss man sich in seinem Script damit beschäftigen. Die Problemstellung selbst: der TE hat Info bekommen, damit sollte er weiter machen können. Bash/Shell-Grundlagen fehlen, muss er sich mit kümmern. Diese Meta-"Diskussionen" und Nabelschauen sind im Übrigen nicht unbedingt zielführend, wie so oft in diesem Forum.
|
Seebär
Anmeldungsdatum: 2. Mai 2009
Beiträge: 829
|
dongxi schrieb: Nunja, ein gutes neues Jahr allerseits 😉 Mein Problem (außer daß ich keine Ahnung habe) scheint folgendes zu sein: Wenn ich aconnect mit gui nutze, dann ist zu sehen, daß ein Port dazukommt, wenn qsynth gestartet ist.
aconnect kann diesen Port also erst ansteuern, wenn qsynth vollständig läuft. Vorher passiert einfach nichts, weil der Port nicht vorhanden ist.
Aha, die Problemstellung musst du schon mal vorher geben, das ist ja nun was anders. Somit willst Du
Folgender Ansatz:
grundsätzlich zuerst App-1 starten mit fire & forget (im Hintergrund). vor App-2 Start: prüfen der Bedingung "ist mein Port da?" Wenn nein: warten n Sekunden, erneut prüfen, wenn ja, app-2 starten. Abbruch nach n Retrys Alternativ, wenn Prüfen der Vorbedingung nicht geht: simpler sleep, der "lange genug" wartet. Hat halt den Nachteil, dass das zu lange / zu kurz sein kann. Kann aber die pragmatische Lösung sein.
Um zu prüfen ob + wer einen Port belegt könnte man netstat verwenden. Vllt, geht es auch anders. Somit brauchste du in deinem Script so was wie
Das mal zusammensuchen und schrittweise zusammenbauen, lernste was und kommst ans Ziel.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Seebär schrieb: Diese Meta-"Diskussionen" und Nabelschauen sind im Übrigen nicht unbedingt zielführend, wie so oft in diesem Forum.
Ich kann Dir sagen, dass mir das auch total auf den Geist geht... und es liegt immer an der Unfähigkeit oder Willenlosigkeit einiger weniger Leute, sich einfach nur sachlich zu äußern und auf diffamierende Äußerungen zu verzichten. Die extreme Form ist es, etwas Zusammenhanglos als "Humbug" hinzustellen, ohne auch nur ein einzige richtigstellende Erklärung beizusteuern. Was soll dieser Sch**ss? Das ist doch genau diese penetrante Überheblichkeit, die jegliches Foren-Klima vergiftet und ständig wiederholt Konfliktauslöser ist. Stattdessen wäre es doch besser, einfach nur sachlich zu bleiben und Aussagen mit Argumenten zu widerlegen...OHNE den Gesprächspartner oder den Text zu bewerten. Ich bin der Meinung, dass es bei einem solchen Anfänger-Kennntnisstand überhaupt nicht darauf ankommt, ob ein abschließender exit 0 möglicherweise sinnfrei ist, sondern allenfalls um das Verständnis "Eine Anwendung beendet sich immer mit einem Return-Code"... wobei selbst das zum jetzigen Zeitpunkt vielleicht noch zu anspruchsvoll ist. Mich kotzt jedenfalls solcherart profilneurotische Besserwisserei (Humbug), die hier gar keinen Erfolg haben kann, mittlerweile immer mehr an. Ich will diese Meta-Diskussion natürlich nicht weiter führen, aber was Du sagst, teile ich. Bearbeitet von sebix: Bitte verwende in Zukunft Zitate, um die Übersicht im Forum zu verbessern!
|