xterm mit zusätzlichem command öffnen (fluxboxmenue)

[michaa7]

Ich öffne in meinem fluxboxmen xterm mit dem folgenden menüeintrag:

Code: Alles auswählen

[exec] (xterm) {xterm -fa 'Mono' -fs 18 -geometry +300+150}

Das funktioniert so auch.

Ich würde mir gerne einen weiteren starter bauen der xterm startet und direkt einfolgendes command ausführt:

Code: Alles auswählen

lsblk --sort mountpoint  -o mountpoint,label,name

Ich habe versucht das ganz oder teilweise anzuhängen, aber das klappt so nicht (weshalb ich diese fehlversuche auch nicht poste).

Kann mir hier jemand erklären ob das überhaupt geht und wie ich das zusammensetzen müsste?

[schwedenmann]

Hallo



{xterm -fa 'Mono' -fs 18 -geometry +300+150 -e lsblk --sort mountpoint -o mountpoint,label,name


mfg
schwedenmann}

[michaa7]

Danke.

Die "-e" hätte ich beinahe übersehen. Klappt aber leider immer noch nicht (Hast du das ausprobiert?). Ich vermute es liegt daran dass lsblk rootrechte voraussetzt ... ma schaun ...

[willy4711]

lsblk brauch keine Root-Rechte
In xterm bekomme ich das Ergebnis auch nicht geöffnet, aber mit einem Editor:

Code: Alles auswählen

#!/bin/bash
xterm -e "lsblk --sort mountpoint -o mountpoint,label,name >xyz"
mousepad xyz
#optional:
rm xyz

[Livingston]

Standarddebianig braucht lsblk keine root-Rechte. Versuch's doch erst mal mit nem dummy, z.B. echo huhu. Außerdem würde ich das Kommando hinter -e mit "" quoten.

Das hier z.B. klappt bei mir:

Code: Alles auswählen

xterm -fa 'Mono' -fs 18 -geometry +300+150 -e "echo huhu; sleep 5"

[michaa7]

... das sleep hat ja seinen Grund. Ich hatte auch schon geargwöhnt, dass das eigentliche Problem die "-e" Option ist, denn an sich klappt das anhängen des commands. Nur schließt sich das Fenster so schnell, dass man nichts sieht. Mit sleep funktioniert auch das anhängen von lsblk (was natürlich keine root Rechte voraussetzt, das habe ich mit blkid verwechselt)

Die "-e" Option schließt offensichtlich das VT sofort nach ausführen des commands. Entweder ist also "-e" die falsche Option (man bräuchte eine die das Terminal offen hält, also das command ausführt, anzeigt und nach drücken der Eingabe einen Promt bereitstellt) oder man müsste das als weitere Option anhängen. Nur wie?


@ willy:

Danke auch dir, mit nem script will ich da nicht rumfummeln. Ich möchte das auf die angefragte art machen weil ich eben nach dem ausführen des commands das VT bereit haben will. Kann mir sonst auch ein alias basteln, welches ich in xterm ausführe, aber bei anderen Programmen habe ich (naja andere, von denen ich das dann kopiert habe ) es ja auch hinbekommen beim öffnen bestimmte dinge ausführen zu lassen.

[eggy]

xterm -e "ls; bash"

[michaa7]

... Wauz-badauz ... genau so klappt das!

Danke ... und wieder was gelernt

[willy4711]

@eggy
Auch von mir
Man weiß ja nie, wofür man das mal braucht.

[eggy]

Naja, die "richtige" Lösung wäre vermutlich mal in die bash-manpage zu schauen, wie man der bash sagt, dass sie vor dem Start noch nen zusätzliches Kommando ausführen soll. Ich geh mal davon aus, dass das irgendwie geht. Könnt ja mal selbst schauen und Rückmeldung geben, ob da was entsprechendes drinsteht.

[michaa7]

Du scherzt. "man bash" ist gefühlt ein mehrbändiges Telefonbuch mit komprimierten Einträgen ... Dort kann man nichts finden. Darüber kann man bestenfalls innerhalb eines Informatkstudiums ne Hausarbeit schreiben ....

Und kürzer kann das auch kaum werden. Ich bin happy mit dem Eintrag in meinem fluxbox Menue, zu dem ich nun jedoch ein anders command nutze weil damit die Ausgabe passender zu steuern ist:

Code: Alles auswählen

[exec] (findmnt) {xterm -fa 'Mono' -fs 18 -geometry +300+150 -e "findmnt -l -o TARGET,LABEL,SOURCE,AVAIL --real|grep -v '/sys'; bash"}

[eggy]

Du scherzt.

NIEMALS. Über sowas macht man doch keine Scherze .

Ich halts für ne interessante Fragestellung, zu der ich in der Manpage leider nichts gefunden hab. Sollte das tatsächlich nicht möglich sein (was ich mir eigentlich nicht vorstellen kann), bleibt noch nen fieser Hack: temporäre bashrc/profile anlegen und die bash damit starten. Grusliger Umweg.

Bei der bisherigen Lösung laufen die beiden Programme (ls bzw bash) von der Prozessverschachteltungsebene ja praktisch "nebeneinander", auch wenn der erste Task bereits wieder tot ist, wenn der zweite gestartet wird. Könnte mir vorstellen, es gibt Situationen, wo das wirklich mal nötig wäre, dass das Programm "innerhalb" bzw "unterhalb" der neuen bash läuft.

Für Deinen Fall ist das Problem zwar vom Tisch, aus akademischer Sicht aber immernoch ne interessante Baustelle...

[MSfree]

Naja, die "richtige" Lösung wäre vermutlich mal in die bash-manpage zu schauen, wie man der bash sagt, dass sie vor dem Start noch nen zusätzliches Kommando ausführen soll.

Öhm, wie soll denn das gehen?

Du startest etwas, und dann soll nachdem es bereits läuft, noch schnell was vorweg abgearbeitet werden?
Da wird dir keine man-page auf der ganzen Welt sagen können, wie du dieses Kunststück vollbringen kannst, und Zeitreisen snd meines Wissens nach noch nicht möglich.

[eggy]

Öhm, wie soll denn das gehen?

Durch gesetzte Umgebungsvariablen oder mitgegebene Parameter, z.B.. So wie jedes andere Programm ebenfalls mitgeteilt bekommt, was es tun soll.

"Start" war vielleicht etwas missverständlich ausgedrückt, meinte natürlich nicht den "Programmstart", sondern "Bereit für User-Eingabe"-Startzustand.

[michaa7]

Du scherzt.

NIEMALS. Über sowas macht man doch keine Scherze .

...
Bei der bisherigen Lösung laufen die beiden Programme (ls bzw bash) von der Prozessverschachteltungsebene ja praktisch "nebeneinander", auch wenn der erste Task bereits wieder tot ist, wenn der zweite gestartet wird. ...

Also ich habe davon ja nicht viel Ahnung, aber ist es nicht so, dass xterm beim Start die Standartshell (hier bash) öffnet um damit lsblk ausführen *zu können* (was ist den xterm oder jedes andere VT ohne ne shell?), diese aber nach der Abarbeitung sofort wieder schließt. Daher muß sie erneut geöffnet werden ...

Ist diese Vorstellung falsch?

[willy4711]

Und kürzer kann das auch kaum werden. Ich bin happy mit dem Eintrag in meinem fluxbox Menue, zu dem ich nun jedoch ein anders command nutze weil damit die Ausgabe passender zu steuern ist:

Möchte nochmal - obwohl du dich ja entschieden hast - einen Stab für lsblk brechen.
Ich finde, dass lsblk jede Menge Möglichkeiten (ich denke mehr als findmnt) hat.
Das wäre in etwa gleichwertig mit deinem Ansatz, ein paar Angaben mehr, die man auch weglassen kann.

Code: Alles auswählen

xterm -fa 'Mono' -fs 18 -geometry +300+150 -e "lsblk --output  KNAME,FSTYPE,FSSIZE,FSAVAIL,LABEL,MOUNTPOINT|grep 'KNAME\|/';bash"

[michaa7]

Danke.

Dir scheint, wenn ich so deine Beispiele nachverfolge, eine Ordnung ausgehend von den raw devices erstrebenswert. Ich orientiere mich am tree und mache eine entsprechend sortierte Liste zur Basis meiner Übersicht. Das kann man mit beiden hier angesprochenen commands erreichen.
Das ist für mich daher gar nicht eine Bevorzugung des Einen oder Anderen sondern einfach eine stetige Annäherung an meine Wunschvorstellung, je nachdem wie ich die commands durchblicke . Da habe ich in diesem Thread einiges gelernt.

Mittlerweile bin ich hier angekommen (die fluxbox-umhüllung habe ich hier weggelassen):

Code: Alles auswählen

lsblk --sort mountpoint -o mountpoint,label,name,FSAVAIL| egrep -e "/" -e "FSAVAIL"

[Livingston]

Apropos man page:

-hold Turn on the hold resource, i.e., xterm will not immediately destroy its window when the shell command
completes. It will wait until you use the window manager to destroy/kill the window, or if you use
the menu entries that send a signal, e.g., HUP or KILL.

Das stammt übrigens aus der xterm-manpage.

...aaalso:

Code: Alles auswählen

xterm -hold -fa 'Mono' -fs 18 -geometry +300+150 -e "echo huhu"

Geht doch

[michaa7]

...

Code: Alles auswählen

xterm -hold -fa 'Mono' -fs 18 -geometry +300+150 -e "echo huhu"

Geht doch

Jain.

Das Fenster bleibt damit zwar offen (man sieht also die Ausgabe).... aber es bleibt unbenutzbar, auch nach Betätigen der Eingabetaste kommt da kein Prompt. "hold" hilft also gerade mal um die Ausgabe sichtbar zu machen, sorgt aber nicht für ein weiter benutzbares VT.

[Meillo]

Ich halts für ne interessante Fragestellung, zu der ich in der Manpage leider nichts gefunden hab. Sollte das tatsächlich nicht möglich sein (was ich mir eigentlich nicht vorstellen kann), bleibt noch nen fieser Hack: temporäre bashrc/profile anlegen und die bash damit starten. Grusliger Umweg.

Bei der bisherigen Lösung laufen die beiden Programme (ls bzw bash) von der Prozessverschachteltungsebene ja praktisch "nebeneinander", auch wenn der erste Task bereits wieder tot ist, wenn der zweite gestartet wird. Könnte mir vorstellen, es gibt Situationen, wo das wirklich mal nötig wäre, dass das Programm "innerhalb" bzw "unterhalb" der neuen bash läuft.

Für Deinen Fall ist das Problem zwar vom Tisch, aus akademischer Sicht aber immernoch ne interessante Baustelle...

Ich denke deine Loesung (xterm -e 'ls;bash') ist vermutlich schon bestmoeglich.

Was das Vorher-Ausfuehren von Befehlen in der Shell angeht, faellt mir auch nur eine temporaere bashrc ein. (Die wird aber vermutlich non-interative abgearbeitet, falls das relevant waere.)

Ansonsten bin ich noch auf die Idee gekommen, dass man vielleicht in den Prompt ($PS1) einen Befehl einbauen koennte (das geht in der Bash bestimmt), dann die neue Shell starten und nach dem gewuenschten Befehl den Prompt wieder zuruecksetzen. Das waere noch viel mehr Hack ... aber irgendwie auch spannend.

Als einzigen evtl. vorhandenen Nachteil deiner Loesung koennte ich mir denken, dass der Vorbefehl nicht in der Shell-History landet. Aber das haengt moeglicherweise davon ab wie die konfiguriert ist.

[eggy]

Ansonsten bin ich noch auf die Idee gekommen, dass man vielleicht in den Prompt ($PS1) einen Befehl einbauen koennte (das geht in der Bash bestimmt), dann die neue Shell starten und nach dem gewuenschten Befehl den Prompt wieder zuruecksetzen. Das waere noch viel mehr Hack ... aber irgendwie auch spannend.

Als einzigen evtl. vorhandenen Nachteil deiner Loesung koennte ich mir denken, dass der Vorbefehl nicht in der Shell-History landet. Aber das haengt moeglicherweise davon ab wie die konfiguriert ist.

den könnt man ja auch noch händisch in die History reinfrickeln ... Ohje, wird immer schlimmer

[tobo]

Ansonsten bin ich noch auf die Idee gekommen, dass man vielleicht in den Prompt ($PS1) einen Befehl einbauen koennte (das geht in der Bash bestimmt), dann die neue Shell starten und nach dem gewuenschten Befehl den Prompt wieder zuruecksetzen. Das waere noch viel mehr Hack ...

Das wäre doch kein Hack - der ist doch genau dafür da und der wird doch auch von vielen verändert. Ich rufe bei jedem Prompt eine Funktion auf, lese eine Datei aus und mache den Prompt, in Abhängigkeit zum Benutzer, farbig.

[Meillo]

Ansonsten bin ich noch auf die Idee gekommen, dass man vielleicht in den Prompt ($PS1) einen Befehl einbauen koennte (das geht in der Bash bestimmt), dann die neue Shell starten und nach dem gewuenschten Befehl den Prompt wieder zuruecksetzen. Das waere noch viel mehr Hack ...

Das wäre doch kein Hack - der ist doch genau dafür da und der wird doch auch von vielen verändert. Ich rufe bei jedem Prompt eine Funktion auf, lese eine Datei aus und mache den Prompt, in Abhängigkeit zum Benutzer, farbig.

In der Weise ist das in Ordnung. Im hier diskutierten Fall geht es darum, einen Befehl im Prompt zu nutzen, um beim *Starten* einer *bestimmten* Shell *einmalig* einen Befehl auszufuehren (damit seine Ausgabe im neuen Terminal sichtbar ist). Anschliessend soll der Prompt wieder normal, also ohne den Sonderbefehl sein. Dafuer PS1 zu verwenden finde ich schon recht gehackt, weil verworren, untypisch, unintuitiv, undurchsichtig -- eben das Gegenteil von eggys Vorschlag: xterm -e 'ls;bash' -- aber schon auch irgendwie eine interessante Idee, was ja auch zu einem Hack gehoert.

[tobo]

Im hier diskutierten Fall geht es darum, einen Befehl im Prompt zu nutzen, um beim *Starten* einer *bestimmten* Shell *einmalig* einen Befehl auszufuehren (damit seine Ausgabe im neuen Terminal sichtbar ist). Anschliessend soll der Prompt wieder normal, also ohne den Sonderbefehl sein. Dafuer PS1 zu verwenden finde ich schon recht gehackt, weil verworren, untypisch, unintuitiv, undurchsichtig

Ja, so betrachtet hast du natürlich recht. Ich hatte nur den ersten und die letzen beiden Beiträge gelesen - der Hintergrund war mir also nicht bekannt.

[Meillo]

Kein Problem.