Windows-Umgebungsvariablen

[Robert Allerstorfer]

Hi,

ich würde gerne den CPU-Typ in perl auslesen. In Unix geht das mit

print uname -m;

• als ergebnis erhält man zB. "i686". In WinNT entspricht das der umgebungsvariable PROCESSOR_ARCHITECTURE (=> "x86"). Diese umgebungsvariable kann aber eigenartigerweise nicht mit perl ausgelesen werden. Ein konstrukt

foreach $key (keys(%ENV)) {
print  $key, ": ", $ENV{$key}, "<br>\n";
}

• das alle variablen ausliest, zeigt, dass eben diese nicht dabei ist. Geht das nun gar nicht mit perl unter NT?

danke,
rob.

[Michael Schröpl]

In WinNT entspricht das der umgebungsvariable PROCESSOR_ARCHITECTURE (=> "x86"). Diese umgebungsvariable kann aber eigenartigerweise nicht mit perl ausgelesen werden. Ein konstrukt
foreach $key (keys(%ENV)) {

»»  print  $key, ": ", $ENV{$key}, "

\n";
}

• das alle variablen ausliest, zeigt, dass eben diese nicht dabei ist. Geht das nun gar nicht mit perl unter NT?

Dein Skript funktioniert bei mir (unter Windows NT 4.0 SP4) tadellos.
Eine ähnliche Ausgabe bekomme ich auch, wenn ich eine cmd-Box öffne und das Kommando "set" eingebe.

Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.

D:\DATEN\env>perl env.pl
USERNAME: finsnap<br>
PROMPT: $P$G<br>
PROCESSOR_IDENTIFIER: x86 Family 6 Model 7 Stepping 2, GenuineIntel<br>
PROCESSOR_ARCHITECTURE: x86<br>
OS: Windows_NT<br>
HOMEDRIVE: C:<br>
SYSTEMROOT: C:\WINNT<br>
COMSPEC: C:\WINNT\system32\cmd.exe<br>
WINDIR: C:\WINNT<br>
PATH: d:\software\ACTIVE~1.500\bin;C:\WINNT\system32;C:\WINNT;d:\software\activeperl.5005\bin;d:\sof
tware\textpad<br>
PROCESSOR_REVISION: 0702<br>
NUMBER_OF_PROCESSORS: 1<br>
USERPROFILE: C:\WINNT\Profiles\finsnap<br>
COMPUTERNAME: PC_MS_TEST<br>
TMP: C:\TEMP<br>
TEMP: C:\TEMP<br>
HOMEPATH: <br>
LOGONSERVER: \PC_MS_TEST<br>
USERDOMAIN: PC_MS_TEST<br>
PROCESSOR_LEVEL: 6<br>
OS2LIBPATH: C:\WINNT\system32\os2\dll;<br>
PATHEXT: .COM;.EXE;.BAT;.CMD<br>
SYSTEMDRIVE: C:<br>

D:\DATEN\env>set
COMPUTERNAME=PC_MS_TEST
ComSpec=C:\WINNT\system32\cmd.exe
HOMEDRIVE=C:
HOMEPATH=\ LOGONSERVER=\PC_MS_TEST
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Os2LibPath=C:\WINNT\system32\os2\dll;
Path=d:\software\ACTIVE~1.500\bin;C:\WINNT\system32;C:\WINNT;d:\software\activeperl.5005\bin;d:\soft
ware\textpad
PATHEXT=.COM;.EXE;.BAT;.CMD
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 7 Stepping 2, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0702
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT
TEMP=C:\TEMP
TMP=C:\TEMP
USERDOMAIN=PC_MS_TEST
USERNAME=finsnap
USERPROFILE=C:\WINNT\Profiles\finsnap
windir=C:\WINNT

D:\DATEN\env>

[Robert Allerstorfer]

Hi,

ja, unter der eingabeshell bekommt man andere umgebungavariablen als über CGI!
Vergleich mal die direktausgabe zu "set" und dann dasselbe als CGI mit Perl:

print set;

Da bekommt man die ganzen server-seitigen variablen, aber viele vom OS bleiben verschwiegen.
Im detail:

SERVER_SOFTWARE
GATEWAY_INTERFACE
DOCUMENT_ROOT
REMOTE_ADDR
SERVER_PROTOCOL
SERVER_SIGNATURE
REQUEST_METHOD
SYSTEMROOT
COMSPEC
QUERY_STRING
HTTP_USER_AGENT
WINDIR
PATH
HTTP_ACCEPT
HTTP_CONNECTION
REMOTE_PORT
SERVER_ADDR
HTTP_ACCEPT_LANGUAGE
SCRIPT_NAME
HTTP_ACCEPT_ENCODING
SCRIPT_FILENAME
HTTP_PRAGMA
SERVER_NAME
REQUEST_URI
HTTP_ACCEPT_CHARSET
SERVER_PORT
HTTP_HOST
SERVER_ADMIN

D.h., dass es unmöglich ist, via Perl-CGI-script unter Windows den CPU-typ herauszufinden?

ciao,
rob.

[Calocybe]

Hallo!

ja, unter der eingabeshell bekommt man andere umgebungavariablen als über CGI!

Ein Prozess (das Script) kennt unter WinNT immer nur die Variablen, die ihm der Elternprozess (der Webserver) mitgibt. Wenn Dein Webserver dem Script nicht mehr verraet, dann hast Du wohl schlechte Karten.

Also wenn ich das mit IIS4 auf NT probiere, bekomme ich auch alle Variablen. Mit Apache auf NT habe ich es nicht probiert, aber ich nehme an, Michael verwendet diesen, sodass es dort wohl auch funzt. Welchen Webserver verwendest also Du?

Calocybe

[Robert Allerstorfer]

Also wenn ich das mit IIS4 auf NT probiere, bekomme ich auch alle Variablen. Mit Apache auf NT habe ich es nicht probiert, aber ich nehme an, Michael verwendet diesen, sodass es dort wohl auch funzt. Welchen Webserver verwendest also Du?

Hi,

das ist interessant. Es liegt also an der webserver-software. Ich verwendete Apache und verglich nun die variablen, die Apache bzw. IIS ausgeben:

Beide server geben (bei direktem scriptaufruf, also mit GET) folgende umgebungsvariablen her:

COMSPEC
GATEWAY_INTERFACE
HTTP_ACCEPT
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_CONNECTION
HTTP_HOST
HTTP_USER_AGENT
PATH
REMOTE_ADDR
REQUEST_METHOD
SCRIPT_NAME
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
SYSTEMROOT
WINDIR

Nur von Apache/1.3.9 (Win32) wird noch folgendes hergegeben:

DOCUMENT_ROOT
HTTP_ACCEPT_CHARSET
HTTP_PRAGMA
QUERY_STRING
REMOTE_PORT
REQUEST_URI
SCRIPT_FILENAME
SERVER_ADDR
SERVER_ADMIN
SERVER_SIGNATURE

Microsoft-IIS/4.0 rückt hingegen mit noch viel mehr raus:

COMPUTERNAME
CONTENT_LENGTH
HTTPS
INCLUDE
INSTANCE_ID
LIB
LOCAL_ADDR
NUMBER_OF_PROCESSORS
OS2LIBPATH
OS
PATH_INFO
PATH_TRANSLATED
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVEL
PROCESSOR_REVISION
REMOTE_HOST
SERVER_PORT_SECURE
SYSTEMDRIVE
USERPROFILE

Es scheint also, dass angaben über die CPU auf windoze nur möglich sind, wenn das Microsoft-eigene server-produkt läuft. Vielleicht ist's aber auch nur noch ein zusätzlicher security bug vom Microsoft server.

rob.

[Calocybe]

Hi Ihr 2!

Bin jetzt derhemm und hab mal den Apache angeschmissen (Michael: stimmt, explizit war von Webserver nicht die Rede), und hier bietet sich auch das Bild, dass die meisten CGI-unabhaengigen Variablen nicht gesetzt sind.

Microsoft-IIS/4.0 rückt hingegen mit noch viel mehr raus:

CONTENT_LENGTH
HTTPS
INSTANCE_ID
LOCAL_ADDR
PATH_INFO
PATH_TRANSLATED
REMOTE_HOST
SERVER_PORT_SECURE

Diese nur von IIS uebergebenen Variablen haben zwar etwas mit CGI zu tun, jedoch sind sie wohl nicht Standard bzw. nicht noetig (CONTENT_LENGTH ist z.B. nur fuer POST-Request benoetigt).

Es scheint also, dass angaben über die CPU auf windoze nur möglich sind, wenn das Microsoft-eigene server-produkt läuft. Vielleicht ist's aber auch nur noch ein zusätzlicher security bug vom Microsoft server.

Bug wuerde ich es nicht nennen. Fuer die Sicherheit wird es wohl auch kaum relevant sein, schliesslich weiss man ja selber, welche Scripts man bei sich laufen laesst. Es ist eben einfach so, dass der Apache diese Variablen nicht aus seiner eigenen Environment in die des Scripts rueberkopiert. (Unter Windows (und sicher auch anderswo) gibt man beim Starten eines Kindprozesses ein Array an eine Systemfunktion mit, die die Environment des Childprozesses spezifiziert; oder man gibt nichts mit und sagt, die urspruengliche Umgebung soll verwendet werden.)

Calocybe

[Michael Schröpl]

Es ist eben einfach so, dass der Apache diese Variablen nicht aus seiner eigenen Environment in die des Scripts rueberkopiert. (Unter Windows (und sicher auch anderswo) gibt man beim Starten eines Kindprozesses ein Array an eine Systemfunktion mit, die die Environment des Childprozesses spezifiziert; oder man gibt nichts mit und sagt, die urspruengliche Umgebung soll verwendet werden.)

Klingt nach "Apache Source nehmen, eine Zeile ändern, neu übersetzen".
Auf UNIX hätte ich da keine Angst vor (make & cc), aber auf Windows braucht man ja so was wie eine Entwicklungsumgebung und einen Compiler und ...

[Michael Schröpl]

Mit Apache auf NT habe ich es nicht probiert, aber ich nehme an, Michael verwendet diesen, sodass es dort wohl auch funzt. Welchen Webserver verwendest also Du?

Webserver???

Meinereiner hat das Script über die Commandline ausgeführt (war ja kein CGI-Anschluß drin, und basteln wollte ich keinen). Deshalb habe ich ja extra den Prompt und den genauen Aufruf in mein Posting hineinkopiert.

Kann natürlich gut sein, daß der böse Webserver - welcher auch immer - das schöne Environment nicht durchreicht ...