Zitat

Original von ENTARO
Ist es möglich die Umgebung zu exportieren, so wie Variablen?
Dann wäre das Problem schnell gelöst.

was meinst du damit "in die umgebung exportieren"? was willst du exportieren und wohin? ins environment?
was ist dann gelöst?
hast du die scripte ausprobiert? ich habe dann letztendlich in kill und trap SIGQUIT (nummer 3) genommen und es funktioniert.

Zitat

Original von ENTARO
Sobald ich ein weiteres Script ausführe (automatisch), wechselt es ja die Shell, richtig?

nein das script wechselt überhaupt nichts. wenn das script durch das einstecken des sticks gestartet wird (wie machst du das eigentlich? im usb.agent oder wo?) dann sucht das scripte eine interaktive shell und startet dort den clientet.

Zitat

Kann ich also nicht die Informationen aus der Shell, wo die ganze Sache startet, in die neue exportieren?

wenn dein script durch das einstecken des usb-sticks gestartet wird, hat es doch überhaupt keine verbindung zum terminal.

Zitat

Original von ENTARO
Leider muss ich zugeben, dass ich nicht genau weis, wie das mit dem einstecken funktioniert. Sobald ich den Stick einstecke, startet er das Script, das warschon so, als ich das erstemal mit dieser Maschine herumgewerkelt habe.

also weisst du gar nicht, wie dieses script gestartet wird (welcher daemon oö das vernlasst. ich nehme mal an, das dieses script durch das hotplug system aufgerufen wird.

Zitat

Ist das nicht so, dass wenn ich ein Script habe, welches ein anderes startet, auch die Umgebung gewechselt wird? Denn ansonsten müsste ich doch die von mir gewünschten ausgaben auf den Bildschirm bekommen.

also mal grundsätzlich, wenn in einem script ein anderes eingesouced wird, ist es bestandteil des übergeordneten scriptes und läuft in der selben umgebung. wird durch die schell ein child-prozess aufgerufen, so erbt er die umgebung der shell.

wenn du vom bildschirm sprichts, das hat erst einmal nichts mit einander zu tun. die bash(shell) ist ein kommandointerpreter, also auch "nur" ein kommando. das hat mit dem bildschirm und der tastatur absolut nichts zu tun.
beim systemstart werden durch mehrere getty-prozesse (siehe /etc/inittab) nach einem erfolgreichen login die standardein/ausgabe und der standarderrorkanal einer shell (siehe festlegung in /etc/passwd) mit dem rufenden terminal verbunden. diese shell/bash hat nun ihre ein/ausgabe-kanäle mit einem terminal verbunden und kann etwas von der tastatur entgegennehmen und ausgaben auf dem bildschirm darstellen lassen.
wird eine shell zb im hintergrund durch einen daemonen gestartet (zzb crond oä) dann hat diese shell im allgemeinen kein zugang zu einen terminal und kann deshalb ohne weiteres auch nichts auf dem terminal ausgeben oder eingaben entgegennehmen.

also zwischen shell und terminal besteht ein gravierender unterschied!
wenn die shell mit einem terminal verbunden wird, ist sie interaktiv und du kannst eingaben machen und bekommst die ausgaben auf dem bildschirm angezeigt.

Zitat

Sobald ich ein weiteres Script ausführe (automatisch), wechselt es ja die Shell, richtig?

Jein, .... wenn Du Variablen in dem Skript nutzen moechtest, dann mach' es am Besten so:

. /dasist_der_Pfad_zu_meinen_Variablen/Variablen.sh

DAS LEERZEICHEN ZWISCHEN . und / IST KEIN (!!!) VERSEHEN!!!!

Das muesste dann funktionieren.

Kind regards,

Bernd

natürlich musst du die named-pipe auch anlegen (hab ich in den ersten beiträgen schon beschrieben.
mknod -m777 /tmp/rohr p

startest du das serverscript per hand?
an welchen user sendes du das signal?
funktioniert der client?

Zitat

Das spart nun mindestens 1 posting

...das kann ich wieder ausgleichen (Q.E.D) )

Nach so einem Leerzeichen kann man eine ganze Weile suchen....

die posting-rate: )

quod erat demonstrandum

die fehlermeldung no such file or directory kann nicht mehr kommen, wenn du die named pipe angelegt hast, oder in deinem script ist ein fehler.

qed = quod erat demonstrandum

ps. bonsai war schneller

poste mal bitte die datei .profile aus dem homeverzeichnis vonn root, also /root/.profile

es fehlt der eintrag

trap stickmessage SIGQUIT

in der datei .profile
damit wird die funktion stickmessage an das signal SIGQUIT gebunden.

Zitat

Original von linuxerr
es fehlt der eintrag

trap stickmessage SIGQUIT

in der datei .profile
damit wird die funktion stickmessage an das signal SIGQUIT gebunden.

Damit wird das Signal SIGQUIT von stickmessage() ignoriert.