Verlegung der PlugIns nach .var

[Zwen]

Habs nicht getestet, denke aber so müsste es funktionieren. Ich schreibs jetzt mal als shell skript (geht schneller), dass müsstest du dann eben entspr. in C machen:

cat /proc/self/maps |grep plugins|awk '{print $6}'

Erklärung /proc/self/maps enthält alle für den akt. Prozess gemapten binaries/libraries.
Ein grep auf plugin, sollte dir nur die Zeile der Plugin-Linrary (plugin.so) geben. Die letzte Spalte (Spalte 6) enthält den kompletten Pfad (mit Filename) der library.
Daraus könntest du dann den Pfad zu deinem Shell-Skript basteln...

Zwen

[essu]

Wie wärs mit sowas:

Code: Alles auswählen

#include <iostream>

void plugin_exec(int argc, char *argv[])
{
    char pluginShellScript[120];
    unsigned int i=0;
    for (i=0;i<120;i++)
    {
        pluginShellScript[i]=argv[1][i];
    }
    //cout << "Aufruf von: " << pluginShellScript << endl;
    system(pluginShellScript); 	
    return 0;
}

...den Pfad so wie bei busybox als Parameter übergeben, nur mal als Anregung...

[Zwen]

@essu:
Du kennst nicht wirklich die Plugin-Architektur, oder ?

Zwen

[essu]

[...], oder ?

Naja, ich hab im CVS schon einiges zu plugins gelesen, aber
1 ist mir nicht klar, welche scripten tatsächlich alle eine Rolle spielen,
2. zumal ich mich unter neutrino kaum auskenne,
3. war das obige nur eine Ansatz bzw. die Frage danach, ob dieser Ansatz sinvoll ist
4. gings hier IMHO gar nicht um plugins im Allgemeinen, sondern um die Möglichkeit shell-scripten mit variablen Pfadnamen auszuführen

... meine Frage nach den Quellen hat ja nur überhebliche Reaktionen hervorgerufen. Eine kleine Start-Hilfe für einen Anfänger wie mich, hätte ich schon erwartet. Aber egal, ich finds schon selber raus, dauert halt etwas länger

[stikx]

Code: Alles auswählen

void plugin_exec(int argc,char *argv[])

Genau das geht eben nicht, würde nur gehen wenn main() verwendet würde.
plugin_exec() hat andere Parameter siehe plugin.h, von daher ist ein Übergeben
von Pfad oder ähnlichem eher schwer möglich.

Ich erläutere mal kurz meine Idee, wie ein Generic Script Launcher
aussehen könnte oder imho sollte:
1. Aufruf eines Plugins das unter einem xxx.so Namen im Verzeichnis /var/tuxbox/plugins liegt
und x-beliebig umbenannt und so vervielfältigt werden kann.
2. Plugin checkt seinen eigenen Dateinamen (mein akutes Problem)
3. Plugin greift auf die xxx.cfg zu und liest so was wie Shellname und Shellpfad aus
(2 zusätzliche Parameter)
4. Plugin startet Shell
5. Errorhandling eventuell mit Ausgabe am TV (Datei nicht vorhanden etc.)

@Zwen
Guter Ansatz, hat neue Perspektiven gebracht, aber gestartete plugins stehen
leider nicht im maps (libs und bins schon)
Andere Ideen?

stikx

[Zwen]

Guter Ansatz, hat neue Perspektiven gebracht, aber gestartete plugins stehen
leider nicht im maps (libs und bins schon)

Nenenene, da hast du was falsch gemacht, technisch gesehen ist das plugin auch nur eine lib...
Habs grad mal ins vnc plugin reingehackt, die map enthielt u.a.

Code: Alles auswählen

0f613000-0f623000 r-xp 00000000 00:07 17354      /lib/tuxbox/plugins/vnc.so

Das ist doch ganz klar der Plugin-Name, oder ?

Lass mich raten, du hast in deinem C-Prog ein
system("cat /proc/self/maps")
gemacht, oder ? Das ist natürlich Käse, da "self" ja immer auf den aktuellen Prozess zeigt. Du bekommst damit die maps der shell, die von system() gestartet wird, nicht die MAP des aufrufenden Prozesses...

Machs mal in C, z.B. (warning ugly code !):

Code: Alles auswählen

plugin_exec (void* foo)
{
   char xxx[10000];
   int xx;
   xx=open("/proc/self/maps",O_RDONLY);
   read(xx, xxx, 9999);
   printf("%s\n",xxx);
}

[Zwen]

3. war das obige nur eine Ansatz bzw. die Frage danach, ob dieser Ansatz sinvoll ist
4. gings hier IMHO gar nicht um plugins im Allgemeinen, sondern um die Möglichkeit shell-scripten mit variablen Pfadnamen auszuführen

Nein, es ging hier ausschliesslich um plugins.
Sollte nicht arrogant wirken, aber stikx hat genau 2 Posts über deinem geschreiben, dass es gerade so nicht geht, da plugins kein argv/argnr übergeben bekommen und dann schlägst du genau das vor....

... meine Frage nach den Quellen hat ja nur überhebliche Reaktionen hervorgerufen. Eine kleine Start-Hilfe für einen Anfänger wie mich, hätte ich schon erwartet.

DieMade hat doch schon geschrieben, dass es zu diesem plugin keine sourcen gibt...

Aber egal, ich finds schon selber raus, dauert halt etwas länger

... Fühlt sich dafür aber besser an, IMHO

Zwen

[jmittelst]

Hmmm - ich lese jetzt schon seit Tagen mit, verstehe jetzt aber eigentlich nur noch Bahnhof ;-)
War doch nur ein Vorschlag, ein bisschen Platz umzuverteilen und es leichter zu machen für Nichtskönner wie mich, interessante PlugIns zu installieren.
Hab nochmal nachgedacht, was Platz angeht: wäre es nicht auch interessant, LCD-Skins, Startbild und ähnliches nach .var zu verlagern? Also alles, was zur Individualisierung der Box beitragen kann? Warum z.B. kann ich einen Clockskin nach /var/tuxbox/lcdd hochladen und der Original liegt immer noch im Flash? Macht doch dann keinen Sinn mehr, oder?
cu
Jens
P.S. Bei der generellen Verlegung der PlugIns nach /var steckt noch der Gedanke dahinter, das, wenn das generell im CVS so gemacht wird, keiner, der ein PlugIn entwickelt, dieses für einen anderen Pfad schreibt.

[essu]

1. Nein, es ging hier ausschliesslich um plugins.

2.Sollte nicht arrogant wirken,

3. aber stikx hat genau 2 Posts über deinem geschreiben, dass es gerade so nicht geht, da plugins kein argv/argnr übergeben bekommen und dann schlägst du genau das vor....

zu 1. kann man drüber streiten, tu ich aber nicht

zu 2. du warst nicht gemeint, zwen, ich meinte die 'helo wörld'-Fraktion

zu 3.

Also, ich schreibe den Scriptaufruf gerne neu, wenn mir noch jemand (eventuell der Devs) steckt,
wie ich an die Info des Dateinamens des aktuell gelaunchten Plugins komme. Da hier nicht main() verwendet wird, sondern plugin_exec() habe ich noch keine Möglichkeit gefunden, diese Info einzulesen.

Genau diese Info "Dateiname" gibts aber schon, da das Plugin auf eine cfg gleichen Namens zugreift, zumindest bei Enigma, es sollte dann kein Problem sein, die cfg so zu erweitern, dass dort auch ein Pfad für ein shellscript steht:

Code: Alles auswählen

...
eString FileName = e->d_name;
			if ( FileName.find(".cfg") != eString::npos )
			{
				eString cfgname=(PluginPath[i]+FileName).c_str();
				int ttype=atoi(getInfo(cfgname.c_str(), "type").c_str());
...

aus enigma_plugins.cpp
Ihr könnt mich gerne berichtigen

[Zwen]

Genau diese Info "Dateiname" gibts aber schon, da das Plugin auf eine cfg gleichen Namens zugreift, zumindest bei Enigma, es sollte dann kein Problem sein, die cfg so zu erweitern, dass dort auch ein Pfad für ein shellscript steht:

Das Plugin greift nicht auf die cfg zu! Der Aufrufer (neutrino/enigma) liest die jeweilige cfg zum Plugin um entimmt daraus, welche Parameter sie an das Plugin übergibt. Ich finde es aber nicht angebarcht jetzt die Schnittstelle für dieses eine Plugin aufzuboren (es müsste ja dann wieder alle GUIs geändert werden). Oben hab ich beschrieben, wie man an die benötigte Info kommt, es gibt bestimmt noch anderer Wege, auf jeden Fall ist es möglich...

Zwen

[essu]

[Ich finde es aber nicht angebarcht jetzt die Schnittstelle für dieses eine Plugin aufzuboren (es müsste ja dann wieder alle GUIs geändert werden).

OK, dann verstehe ich dich jetzt, mir ging es allerdings eher um die Schnittstelle, die ich tendenziell (und für meine geheimen Zwechke ) für zu unflexibel halte.
Dieses "eine Plugin" ist mittlerweile sicher schon per HexEditor in einen lauffähigen Zustand gebracht worden, dafür wäre mir der Aufwand jetzt zu gross.
"Aufbohren" wollte ich auch nicht, sondern 'sinnvoll' um ein paar cfg-Details ergänzen, wie ich es hier für Enigma versucht habe (Dieser Versuch ist wahrscheinlich not working, sondern als Frage zu verstehen "Lässt sich das so machen?". I`m a bloody Greenhorn, you know? Just trying do learn things by doing && ASKING.)
Auf jeden Fall mal Danke, zwen, für deine Ausführungen, hat mir schon was gebracht.

[stikx]

Danke Zwen, ich war von Blindheit geschlagen, natürlich self wie der Name schon sagt, ist dynamisch verlinkt.

Dann steht dem Redesign nichts mehr im Weg, es sein denn jemand hat noch eine bahnbrechende Idee wie es anders umgesetzt werden sollte.

@essu
Ist mein Ansatz für die Umsetzung so okay?

stikx

[essu]

1. Aufruf eines Plugins das unter einem xxx.so Namen im Verzeichnis /var/tuxbox/plugins liegt
und x-beliebig umbenannt und so vervielfältigt werden kann.

3. Plugin greift auf die xxx.cfg zu und liest so was wie Shellname und Shellpfad aus
(2 zusätzliche Parameter)

zu 1. Kann es auch ein Link sein? Dann wärs ok.
--edit --
Das Problem ist IMHO, dass dier ganzen shell.so var zumüllen 5K nur für ein shellscript ist zuviel, da hätte ich (für ENIGMA zumindest) eine bessere, wenn auch sicherlich nicht 'saubere' Lösung: Ein (einziges) shell plugin, das aus editierbaren file-bouquets die auszuführenden shell-Befehle liest.

zu 3. Dateiname mit Pfad würde reichen (1 Parameter)

zusätzlich fände ich es gut, wenn man in der cfg die Möglichkeit hätte, weitere Parameter, die an das shellscript weitergereicht werden anzugeben, etwa

shell_params='-q -O /dev/null -bla -bla'

ich weiss aber nicht, ob das mit dem Quotuing so klappt, alternativ eben nur ein Parameter

[stikx]

zu 1. Kann es auch ein Link sein? Dann wärs ok.

Das hängt vom Aufrufer ab, denkbar wärs, aber was für einen Sinn macht es?

Das Problem ist IMHO, dass dier ganzen shell.so var zumüllen 5K nur für ein shellscript ist zuviel, da hätte ich (für ENIGMA zumindest) eine bessere, wenn auch sicherlich nicht 'saubere' Lösung: Ein (einziges) shell plugin, das aus editierbaren file-bouquets die auszuführenden shell-Befehle liest.

Teilweise ACK, aber 1. Etappenziel wird dieses Generic Shell Plugin.
2. Etappenziel Deine RC-Abfrage in der Shell mit Hilfe dieses Plugins
Danach schauen wir mal was noch drin ist. Eventuell leite ich dann
davon auch noch diesen Wunsch ab.

zu 3. Dateiname mit Pfad würde reichen (1 Parameter

ich schau's mir an was mehr Sinn macht.

zusätzlich fände ich es gut, wenn man in der cfg die Möglichkeit hätte, weitere Parameter, die an das shellscript weitergereicht werden anzugeben, etwa

shell_params='-q -O /dev/null -bla -bla'

ich weiss aber nicht, ob das mit dem Quotuing so klappt, alternativ eben nur ein Parameter

Macht sogar sehr viel Sinn, kommt mit rein.

Jetzt lass mich mal loslegen, wenn ich was habe, schick ich Dir den Kram zum Testen
stikx

[essu]

zu 1. Kann es auch ein Link sein? Dann wärs ok.

Das hängt vom Aufrufer ab, denkbar wärs, aber was für einen Sinn macht es?

Erst mal bin ich unheimlich gespannt auf deine Lösung....

Nochmal zu dem obigen, weil du skeptisch bist: Du weisst ja wie busybox funktioniert, alle Befehle sind nur Links auf busybox und busybox entscheidet, was gemacht wird, so ähnlich stelle ich mir das hier auch vor, damit müsste nicht für jedes shell-plugin eine eigene *.so compiled werden, die ziemlich viel Platz verbraucht, obwohl sie nicht viel anderes macht als einen shell-Aufruf weiter zu leiten. Es müsste doch ein Link auf eine entsprechend flexible *.so reichen um alle shell-Aufrufe erledigen zu können, aber ob dann der Name (des Links) noch festgestellt werden kann, weiss ich leider nicht...

[animal]

hiho
so klappt es ist quickndirty(kanns nicht besser)

Code: Alles auswählen

#include <stdio.h> 
#include <plugin.h> 
void plugin_exec() 
{ 
  char scriptname[256], puffer[10000], *ptr1, *ptr2; 
   int xx; 
   xx=open("/proc/self/maps",0); 
   read(xx, puffer, 9999); 
   //printf("%s\n",puffer);
    ptr1 = strchr(puffer,'/');
    ptr2 = strchr(puffer,'.');
    strncpy(scriptname, ptr1, ptr2 - ptr1);
    scriptname[ptr2 - ptr1] = '\0';
    
    printf("Scriptname = %s\n",scriptname);
    
system(scriptname); 
}

/hiho
animal