Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
McHorb
Anmeldungsdatum: 07.02.2009 Beiträge: 4
|
Verfasst am: 08.02.2009, 00:25 Titel: Umgebungsvariable lokal / global |
|
|
Hallo, ich oute mich erst mal als Newbie
Ich wollte über eine Umgebungsvariable einen String von FB zum aufrufenden Batchprogramm zurückgeben. Leider scheint der Inhalt der Umgebungsvariable nicht global gültig zu sein.
In FB (norm.exe) setze und kontrolliere ich die Umgebungsvariable wie folgt:
Code: |
s1 = Environ("filearchiv")
trenner = instr(s1,"-") -1
print "NORM", s1, trenner, val(s1)
# hier wird der String in der Variablen s1 bearbeitet
# und wieder an die Umgebungsvariable zurückgegeben
setenviron "filearchiv="&s1
shell "SET filearchiv" |
Aufgerufen wird das FB-Programm norm.exe aus der Batchdatei wie folgt:
Code: |
...
set filearchiv=%1
norm.exe
set filearchiv |
Im Batchprogramm steht aber nach dem Programmaufruf norm.exe wieder der ursprüngliche Wert in der Umgebungsvariable
Code: |
\Archiv>set filearchiv=35-A.pdf
\Archiv>norm.exe
NORM 35-A.pdf 2 35
0035-A.PDF
filearchiv=0035-A.PDF
\Archiv>set filearchiv
filearchiv=35-A.pdf |
Wie bekomme ich denn alternativ einen Wert an das aufrufende Batchprogamm zurück.
Schon mal herzlichen Dank |
|
Nach oben |
|
 |
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 08.02.2009, 00:41 Titel: |
|
|
Ich würde es per Code: | shell "set FOO=BAR" | machen. |
|
Nach oben |
|
 |
McHorb
Anmeldungsdatum: 07.02.2009 Beiträge: 4
|
Verfasst am: 08.02.2009, 01:18 Titel: |
|
|
28398 hat Folgendes geschrieben: | Ich würde es per Code: | shell "set FOO=BAR" | machen. |
Danke für Deinen Vorschlag. Bei Deinem Beispiel ist der String statisch.
Aber auch die folgende Zeile führt nicht zum Erfolg, der String in s1 wird nicht in der Umgebungsvariablen abgespeichert.
Code: | shell "SET filearchiv="&s1 |
->
Code: | \Archiv>norm.exe
NORM 35-A.pdf 2 35
0035-A.PDF
filearchiv=35-A.pdf |
Es sollte aber natürlich 0035-A.pdf in filearchiv stehen |
|
Nach oben |
|
 |
Muttonhead

Anmeldungsdatum: 26.08.2008 Beiträge: 565 Wohnort: Jüterbog
|
Verfasst am: 08.02.2009, 13:57 Titel: |
|
|
ich glaube, das jede neue Umgebungsvariable nur in der Konsole gültig ist, in der sie mit SET XXX=YY erzeugt wurde, sie ist also immer lokal.
versuche mal 2 eingabeaufforderungen gleichzeitig aufzumachen definiere in der ersten eine neue Variable und versuche
sie in der zweiten sichtbar zu machen.
Du wirst sehen in der zweiten ist deine Variable nicht existent!!!
Und jedes Freebasic SHELL Kommando erzeugt immer eine neue Konsole.
irgendwo in den Systemeinstellungen lassen sich auch neue Umbebungsvariablen vordefinieren.Wenn du dort dein filearchiv einträgst
ist sie nach nem Reset wohl in jeder Konsole gültig, also global
Unter Vista wüsste ich, wo man das einstellt....
edit:
allerdings... wenn man sie verändert so passiert das nur lokal. in jeder neuen Konsole , so auch bei "SHELL" aufruf, enthält die Variable wieder den Ausgangswert
edit2:
die bekloppte Variante:
deine Batchdatei:
Code: |
set Z=alterwert ' Variable erzeugen
set Z >Zwert ' Umlenken der Ausgabe in die Datei ZWert
norm.exe ' dein Programm öffnet ZWert und kann dadurch den
' Wert von Z ermitteln
' dein Programm erzeugt anschliessend selbst eine
' kleine Batch Datei zb "neuZ.bat" mit folgenden
' Inhalt "Set Z=neuerWert".
neuZ.bat ' Aufruf der frisch erzeugte .bat
|
*kopfkratz*
Mutton |
|
Nach oben |
|
 |
McHorb
Anmeldungsdatum: 07.02.2009 Beiträge: 4
|
Verfasst am: 09.02.2009, 22:39 Titel: |
|
|
Muttonhead hat Folgendes geschrieben: | ich glaube, das jede neue Umgebungsvariable nur in der Konsole gültig ist, in der sie mit SET XXX=YY erzeugt wurde, sie ist also immer lokal. |
Yep, ist in der Tat so
Muttonhead hat Folgendes geschrieben: | Und jedes Freebasic SHELL Kommando erzeugt immer eine neue Konsole. |
Genau, manchmal bin ich zu starrsinnig ... SHELL ist das Schlüsselwort
Vielen Dank für Deine Gedankenanstöße |
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 10.02.2009, 09:25 Titel: |
|
|
Siehe dazu
http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/EinbettungBSY.html
Thema "Umgebungsvariablen setzen", d.h. der Vererbemechanismus der Umgebungsvariablen, welcher vom Betriebssystem her kommt, gilt für FreeBasic genauso! Kurz & bündig: Kind-Prozesse erhalten eine Kopie der Umgebungsvariablen-Tabelle, somit gehen Änderungen im Kindprozess bei dessen Beendung verloren.
Abhilfe: Falls Rückgabe nur eine Zahl ist, würde ich auf den Errorlevel zurückgreifen. Wie ich gerade hier sehe, haben die FreeBasic-Entwickler den END-Befehl passend ergänzt, einzig SHELL müssten die Entwickler (Verbesserungsvorschlag!) noch so erweitern, dass der Rückgabewert immer ein Errorlevel ist, wobei ich gerade sehe, mit der Alternative EXEC anstelle von SHELL auch der Errorlevel zurückgeliefert wird.
Übrigens in VBScript steht beides ebenfalls zur Verfügung, d.h.
Code: | WScript.Quit lErrorLevel |
beendet ein .VBS mit einem bestimmten Errorlevel, umgekehrt
Code: | lErrorLevel = oShell.Run("Foobar.exe arg1 arg2", True) |
bekommt man hier den Errorlevel ebenfalls zurück.
Falls mehr als eine Zahl benötigt wird, dann als Vaterprozess dem Kindprozess einen Ausgabe-Dateinamen (COMMAND$!) mitgeben, der Kindprozess schreibt dann dort seinen Output hinein. Falls Konsolenanwendung, dann noch einfacher: Kindprozess den Output auf stdout ausgeben lassen, Vaterprozess ruft Kindprozess mit OPEN PIPE auf. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
McHorb
Anmeldungsdatum: 07.02.2009 Beiträge: 4
|
Verfasst am: 10.02.2009, 11:37 Titel: |
|
|
dreael hat Folgendes geschrieben: | Falls mehr als eine Zahl benötigt wird, dann als Vaterprozess dem Kindprozess einen Ausgabe-Dateinamen (COMMAND$!) mitgeben, der Kindprozess schreibt dann dort seinen Output hinein. Falls Konsolenanwendung, dann noch einfacher: Kindprozess den Output auf stdout ausgeben lassen, Vaterprozess ruft Kindprozess mit OPEN PIPE auf. |
Herzlichen Dank für den informativen Excurs  |
|
Nach oben |
|
 |
|