Linux 15.070 Themen, 107.540 Beiträge

Batch unter fremden User

heriL / 8 Antworten / Baumansicht Nickles

Hallo, ich brauche nochmal eure Hilfe für ein Batchprogramm.
Das Programm startet u.a. einen Browser, nutzt das read-Kommando und soll unter einer speziellen User-Kennung laufen. Das funktioniert auch, wenn ich es auf einer Konsole von diesem User aus starte. Wenn ich es aber über einen KDE-Desktop-Programmsymbol starte läuft das read-Kommando nicht richtig (der Browser startet korrekt, seit ich "DISPLAY=:0.0" vor den Browser-Aufruf eingefügt habe). Außerdem funktioniert die Kontrolleiste nicht, solange der Batch läuft.

wie kann ich den Fehler beheben oder wo finde ich besser Doku zu diesem "KDE-Desktop-Programmsymbol" ?

Gruß
heriL

bei Antwort benachrichtigen
uscos heriL „Batch unter fremden User“
Optionen

was machst du da. bzw was willst du machen? Das hoert sich alles erstmal ziemlich falsch an. Wenn du ein Programm als anderer user starten willst schreit das erstmal nach su oder sudo.

bei Antwort benachrichtigen
heriL Nachtrag zu: „Batch unter fremden User“
Optionen

ja, natürlich; so läuft's ja auch; ich will das Programm / den Batch aber vom Desktop aus starten.

In der ersten Ausbaustufe war es einfach: ich habe den Browser mit Hilfe des KDE-Desktop-Programmsymbols unter dem speziellen User aufgerufen. Jetzt will ich aber gleichzeitig ein 2. Programm aufrufen, daher der Start des Browser vom Batchproramm ;-)
aber aus irgendeinem Grund spielt "ead" nicht mit und die Kontrolleiste blockiert.

Gruß
heriL

bei Antwort benachrichtigen
uscos heriL „ja, natürlich so läuft s ja auch ich will das Programm / den Batch aber vom...“
Optionen

ich glaube hier sagt code mehr als 1000 worte.

bei Antwort benachrichtigen
KarstenW heriL „Batch unter fremden User“
Optionen

Das wird so nicht funktionieren. read ist ein built in Kommando von der bash und kann Daten von der Tastatur einlesen.
Das funktioniert über den Standardeingabekanal. Der Standardeingabekanal ist ein Puffer vom Betriebsystem der automatisch geöffnet wird, sobald ein Programm in der Konsole im Textmodus gestartet wird.

Programme die im Grafikmodus laufen funktionieren anders.
Die Steuerelemente oder Fenster (oder Widgets bei Unix/Linux) senden Signale oder Nachrichten wenn der Benutzer mit dem Programm interagiert, die das jeweilige Programm abfängt und daraufhin eine bestimmte Funktion aufruft.
Also ein Programm welches im Grafikmodus läuft nutzt weder den Standardeingabekanal noch den Standardausgabekanal (auch nicht den Standardfehlerkanal) vom Betriebsystem.

Das Shellscript kann so ein Signal gar nicht abfangen und daraufhin reagieren, weil dazu die Bash nicht in der Lage ist und deshalb kann read keine Daten lesen, die du in einem Fenster im Grafikmodus eingibst.

Wenn du Shellscripte programmierst die Daten von der Tastatur einlesen, dann kannst du dieses Shellscript nur in einem Terminalfenster starten oder in der Konsole.

Du mußt ein richtiges KDE-Programm mit der QT Bibliothek schreiben (vielleicht ein einfaches Dialogfenster (-programm), welches die Daten im Grafikmodus von der Tastatur einlesen kann.
Shellscripte laufen nur in der Konsole (oder in einem Terminalfenster) , im Texmodus .

PS: Das gleiche Problem hast du wenn du ein Batchprogramm für DOS/Windows schreibst. Diese Batchprogramme laufen auch nur in der Eingabeaufforderung unter Windows. Die Eingabeaufforderung bei Windows ist so ein Art Shell oder Kommadointerpreter wie bei Unix/Linux, aber mit weniger Möglichkeiten.

PPS: Unter Linux/Unix schreibt man Shellscripte und keine Batchprogramme wie bei DOS/Windows ;-).

http://www.tldp.org/LDP/abs/html/internal.html








Debian GNU/Linux https://www.debian.org/index.de.html
bei Antwort benachrichtigen
KarstenW heriL „Batch unter fremden User“
Optionen

Ich habe es eventuell falsch erklärt.
Da fehlt eine Verbindung zwischen den beiden Programmen. read ließt die Daten von der Tastatur und speichert sie in einer Variable ab.
Wie kann jetzt das zweite Programm, welches im Grafikmodus läuft, auf diese Variable von read zugreifen ?
Das geht eben nicht.

Der Linuxkernel bietet System V Interprozesskommunikation an. Dieses Konzept stammt ursprünglich von AT&T Unix System V.
Dadurch wurden auch diese Pipes erst möglich.
Die Ausgabe des ersten Programmes wird zur Eingabe des zweiten Programmes.
Beispiel:

"ps ax | grep firefox"

Das funktioniert aber nur mit Programmen die in der Konsole laufen und nicht mit Programme die für den Grafikmodus programmiert wurden (weil Programme die im Grafikmodus laufen den Standardeingabekanal und den Standardausgabekanal nicht nutzen).
Für die Eingabe und Ausgabe verwenden Programme die im Grafikmodus laufen spezielle Funktionen.







Debian GNU/Linux https://www.debian.org/index.de.html
bei Antwort benachrichtigen
heriL KarstenW „Ich habe es eventuell falsch erklärt. Da fehlt eine Verbindung zwischen den...“
Optionen

ok, aber KDE bietet Programmsymbole an; deren Parameter erlauben ein Programm in einem Terminal und von einem anderen User zu starten. außerdem gibt es Parameter zur dcop-Registrierung, die für mich nicht selbsterklärend sind: "Im Systemabschnitt der Kontrolleiste anzeigen" und dcop-Registrierung: Bis zum Abschluß durchlaufen lassen" (eine Beschreibung dazu suche ich noch).

ok, ich habe mir gerade die Prozesse angesehen und der Ablauf ist folgender:
konsole > su > ksystraycmd > skript > opera mit dem Klick auf das Programmsymbol startet su und die übrigen Programm folgen.
es öffnet sich ein Terminalfenster in dem das Skript (sorry für den Fautpas) abläuft - das read-Kommando wird übergangen und die folgende if-Abfrage, die eine Eingabe aus dem read erwartet, läuft auf eine Fehler; opera startet und die Kontrolleiste ist blockiert

mit sudo vom Terminalfenster aus gestartet sieht das so aus:
konsole > bash > skript > opera (Voraussetzung: xhost +)

wie uscos vorgeschlagen hat, habe ich den Code unten reinkopiert,
Gruß
heriL

--------------------------------
#! /bin/sh
#start
echo start
DISPLAY=:0.0 opera -nomail >~/operatmp.txt 2>&1 &
pid=$!
echo "opera-pid = "$pid
echo "warten auf opera ende" #test
read -p "tmp öffnen? (y/n)" goon
echo $goon
if [ $goon = "y" ];
then
container="/x-inet/tmp-i.toc"
mountdir="/x-inet/download/tmpsik"
echo "1- " #start $mountdir mounten"
#echo `truecrypt -v -l`
echo "2- " #truecrypt -v -u $container $mountdir"
truecrypt -v -u $container $mountdir
ifopen=`truecrypt -l 2>&1`
echo "3- " #gemountete Container: "$ifopen
if [ "$ifopen" = "No volumes mapped" ]; then
echo "mounten nicht gelungen"; else
touch $mountdir/"last-open-dat"
echo "5- $container gemountet unter $mountdir"
ls -l $mountdir;
fi
wait $pid
truecrypt -v -d $mountdir
echo 6-;
else
wait $pid
fi
#wait $pid
echo "opera ende"
rm ~/operatmp.txt
exit 0
--------------------------------

bei Antwort benachrichtigen
heriL Nachtrag zu: „ok, aber KDE bietet Programmsymbole an deren Parameter erlauben ein Programm in...“
Optionen

p.s.
ich habe übrigens andere Skripte, die ich über Programmsymbole starte und die das read-Kommando nutzen - sie laufen einwandfrei. Es muß an dem fremden User liegen.
Gruß
heriL

bei Antwort benachrichtigen
KarstenW heriL „p.s. ich habe übrigens andere Skripte, die ich über Programmsymbole starte und...“
Optionen

Ich bin auch nicht der große BASH Experte ;-).
Ich habe mal versucht das Problem nachzuvollziehen. Gib mal in einer Konsole diese Befehle ein, um zu testen was bei den einzelnen Scriptbefehlen passiert:

~$ su ; read test ; echo $test
Password:
# exit
exit
erfolgreich
erfolgreich


Du startest mit su eine neue Shell und verläßt damit die Programmumgebung.

Wenn man ein Shellscript startet, dann startet die Shell eine neue Shell (wegen dem Pseudokommentar #!/bin/bash) in der das Shellscript dann läuft. Dabei wird auch die gesamte Umgebung (Umgebungsvariablen) vererbt.
Das ist bei Unix Standard. Ein Prozess startet einen Kindprozess mit Hilfe des Systemaufrufs fork() und dann wird durch den Systemaufruf execl() der Kindprozess durch den eigentlichen Prozess ersetzt. Dabei werden auch alle Rechte vererbt.

Besser kann ich es nicht erlären.

PS: Wozu brauchst du su ?

PPS: Kauf dir mal ein Lehrbuch für die Shellprogrammierung:

http://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Daps&field-keywords=Shellprogrammierung+Krienke&x=0&y=0





Debian GNU/Linux https://www.debian.org/index.de.html
bei Antwort benachrichtigen