Backquote unter Windows (Allgemeines zu Perl)

[thread]19471[/thread]

Backquote unter Windows

Tags: perl5 windows 7 Ähnliche Threads

Leser: 13

Articles: hide open all | hide show old branches

+17 replies
tonewheel

2015-01-20 23:11
User since
2006-10-01
182 Artikel
BenutzerIn
Hi,
da ich nur wenig mit Windows zu tun habe (und entsprechend keine Ahnung von den internen Dingen), jedoch meine CAD-Software in der Firma unter Windows läuft, frage ich mal hier.
Die CAD-Soft wird über ein Perlscript gestartet. Betriebssystem ist Windows-7 Professional (64 Bit). Perl-Version ist noch 5.8.x, habe aber auch mit Strawberry-Perl 5.20 getestet. Seit kurzem gibt es Probleme auf einigen dieser Recher (aber nicht auf allen, daher vermute ich ein Windowsproblem). Im Perlscript konnte ich das ganze auf folgendes Problem einkreisen (eigentlich nicht mein Job, wir haben eine IT, versuche nur, ein wenig zu unterstützen):
Code (perl): (dl )

my $windowsversion = `VER`;
In der darauf folgenden Zeile (regexp auf $windowsversion) kommt eine Warnung, dass $windowsversion nicht initialisiert ist.
In der Kommandoshell (cmd.exe) gibt ver die aktuelle Windowsversion aus, aus Perl heraus funktioniert das nicht auf allen Rechnern.

Ein weiterer Versuch
Code (perl): (dl )

print system $ver;
sagt, dass cmd.exe nicht gefunden wird und daher nicht gestartet werden kann. Auf einem Teil der Rechner (also da, wo auch backquote funtioniert), funktioniert das aber problemlos.

Vor ein paar Tagen hat das alles noch funktioniert. Weiß jemand, was mit Windows geschehen kann/muss, sodass dieses Problem auf einigen, aber nicht allen Rechnern auftritt? Laut IT sind überall die gleichen Upates, usw. drauf.

Danke für Antworten!
- rosti
  
  2015-01-21 07:24
  User since
  2011-03-19
  3471 Artikel
  BenutzerIn
  Wenn möglich, verzichte auf Systemkommandos und nutze entsprechende Module, was Deine Scripts portabler macht. Die Version auslesen ist ganz einfach mit Win32::GetOSVersion(), Beispiel:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6
  
  use strict; use warnings; use Data::Dumper; use Win32; print Dumper @{[Win32::GetOSVersion()]};
  
  Die Ausgabe sieht so aus:
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9
  
  $VAR1 = 'Service Pack 3'; $VAR2 = 5; $VAR3 = 1; $VAR4 = 2600; $VAR5 = 2; $VAR6 = 3; $VAR7 = 0; $VAR8 = 256; $VAR9 = 1;
  
  Du findest darin das, was c:\>ver => Microsoft Windows XP [Version 5.1.2600] auch ausgibt.
  Last edited: 2015-01-21 09:00:18 +0100 (CET)
- +14 replies
- GwenDragon
  
  2015-01-21 08:48
  User since
  2005-01-17
  14746 Artikel
  Admin1
  Windows 7 x64:
  
  Code (perl): (dl )
  
  1 2
  
  my $version = qx(VER); say $version;
  
  Microsoft Windows [Version 6.1.7601]
  
  //EDIT:
  cmd.exe ist auf einem 64bit Windows normalerweise unter:
  C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.17514_none_f387767e655cd5ab\cmd.exe C:\Windows\SysWOW64\cmd.exe C:\Windows\System32\cmd.exe
  
  Wie ist denn der Pfad in deinem Perl-Programm?
  
  Code (perl): (dl )
  
  say $ENV{PATH};
  
  Und hast du ein 32bit oder 64bit-Perl?
  Last edited: 2015-01-21 09:07:44 +0100 (CET)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - +13 replies
  - tonewheel
    
    2015-01-21 11:00
    
    User since
    2006-10-01
    182 Artikel
    BenutzerIn
    
    Hallo,
    
    Rosti's Script geht auf den betreffenden Rechnern und zeigt auch überall das Gleiche an. GewnDragon's Script geht nach wie vor nur auf einem Teil der Rechner, da wo es nicht geht, kommt:
    
    Quote
    Use of uninitialized value $version in concatenation (.) or string
    
    cmd.exe ist bei allen Rechnern in C:\windows\System32 und das ist auch im Pfad enthalten (path wird sowohl in der shell, wie auch aus Perl heraus richtig angezeigt). Perl ist 64 Bit.
    
    Also muss doch irgendwo innerhalb der Windows-Installationen was anders sein?!
    - +12 replies
    - GwenDragon
      
      2015-01-21 14:15
      
      User since
      2005-01-17
      14746 Artikel
      Admin1
      
      Logisch geht Rostis Programm immer, weil das ein Windows-Systemaufruf ist.
      
      Warum das Beispiel mit den Backticks bzw. qx nicht auf allen Rechnern läuft, ist mir unverständlich.
      Was passiert denn bei:
      
      Code (perl): (dl )
      
      1 2
      
      my $version = qx(C:\\Windows\\system32\\cmd.exe /c VER); print $version;
      
      Ich kann's nicht testen, weil bei mir auf dem Entwicklungs-Windows-7 nur 32bit Perl wegen diverser externer Windowsdienste wie Apache, mod_perl etc. installiert ist
      die Drachin Gwen
      
      Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
      - +11 replies
      - tonewheel
        
        2015-01-21 15:18
        
        User since
        2006-10-01
        182 Artikel
        BenutzerIn
        
        2015-01-21T13:15:51 GwenDragon
        Logisch geht Rostis Programm immer, weil das ein Windows-Systemaufruf ist.
        
        Warum das Beispiel mit den Backticks bzw. qx nicht auf allen Rechnern läuft, ist mir unverständlich.
        Was passiert denn bei:
        
        Code (perl): (dl )
        
        1 2
        
        my $version = qx(C:\\Windows\\system32\\cmd.exe /c VER); print $version;
        
        Ich kann's nicht testen, weil bei mir auf dem Entwicklungs-Windows-7 nur 32bit Perl wegen diverser externer Windowsdienste wie Apache, mod_perl etc. installiert ist
        
        Kurz vor Feieraben im letzten Moment getestet: :-)
        
        Quote
        Microsoft Windows [Version 6.1.7601]
        
        Geht auf einem der Rechner, wo es bisher nicht funktionierte. Was sagt das jetzt aus?
        
        GwenDragon
        
        2015-01-21 15:24
        
        User since
        2005-01-17
        14746 Artikel
        Admin1
        
        Dass wohl die cmd nur mit Pfadangabe korrekt aufgerufen werden kann.
        Aber was weiß ich.
        
        Es ist jedenfalls sinnvoller sich nicht eben so mal auf irgendwelche angeblich vorhanden Suchpfade bei Perl/Shell/Batch-Programmen zu verlassen, wenn eine externe Shell aufgerufen wird.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        Linuxer
        
        2015-01-21 15:47
        
        User since
        2006-01-27
        3890 Artikel
        HausmeisterIn
        
        2015-01-21T14:18:37 tonewheel
        Geht auf einem der Rechner, wo es bisher nicht funktionierte. Was sagt das jetzt aus?
        
        Dass das Thema für Aussenstehende nur schwer nachzuvollziehen ist.
        
        Wenn anscheinend "cmd.exe" nicht gefunden wird, muss halt kontrolliert werden, welcher Pfad im Skript zur Laufzeit bekannt ist. Welcher Benutzer führt das Skript letzenendes aus? Ggfs. hat der ganz andere Umgebungsvariablen und dort ganz andere Werte als der Benutzer, der es entwickelt und testet?
        
        Arbeite entweder mit absoluten Pfaden oder setze zu Beginn des Skript die benötigten Umgebungsvariablen auf zuverlässige Werte.
        meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
        Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
        
        +8 replies
        
        Raubtier
        
        2015-01-21 16:08
        
        User since
        2012-05-04
        1075 Artikel
        BenutzerIn
        
        Ist die Umgebungsvariable comspec (Klein-/Großschreibung mag anders sein) gesetzt? Auf was?
        
        +6 replies
        
        tonewheel
        
        2015-01-21 21:07
        
        User since
        2006-10-01
        182 Artikel
        BenutzerIn
        
        Hallo Zusammen,
        
        erstmal danke für die Antworten und die freundliche Hilfe. Ich weiß, dass alle Aussagen sehr vage sind. Leider habe ich auch nicht viel mehr in der Hand, kann aber danach suchen, wenn ich weiß, wo ich suchen muss.
        
        Nur mal ein paar Umgebungsinfos zur der Sache:
        Wir sind 14 User, die mit der Software arbeiten. Die Perlscripte wurden laut Kommentaren in 2004 erstellt. Das ganze läuft seit Jahren einwandfrei. Jedoch seit ca. 1 Woche funktioniert es auf etwa der Hälfte der Rechner nicht mehr. Die Software selbst wurde in dem Zeitraum nicht geändert oder upgedatet. Das Einzige, was mir aufgefallen war, war eben der besagte Fehler, der auf den betroffenen Rechnern aufgetreten ist.
        
        Ich habe keine Schreibrechte auf die Scripte, kann daher auch keine Pfade usw. ändern. Da das Zeug aber schon ewig läuft, alle User die gleichen Rechte haben, usw. liegt es nahe, dass sich am Betriebssystem selbst was geändert hat, was zum Nichtfunktionieren führt. Dass es nur die Hälfte der Rechner betrifft, macht es das umso schwieriger.
        
        Ich halte die Meinung von Linuxer am wahrscheinlichsten, nämlich dass das Script zur Laufzeit die Pfade nicht mehr kennt, die ansonsten in einer manuell geöffneten shell gesetzt sind. Nur warum das so ist, und dann auch nur bei der Hälfte, ist fraglich.
        
        Der Fehler ansich trat in einem Perlmodul auf, welches nach Aufruf eines anderen Perlscripts (durch einen Link auf einer Webseite gestartet) durchlaufen wird. Anschließend startet ein Perl/TK-Script, in dem man ein paar Parameter einstellen kann, die der CAD-Software mitgegeben werden, welche letztlich durch einen Button aus dem Script heraus gestartet wird. Also viele Ecken, an denen was schiefgehen oder verloren gehen kann.
        
        Die entsprechende if-Abfrage (bzgl. windowsversion) hatte ich zum Test überbrückt ( bzw. von der IT ausprobieren lassen, habe ja keine Schreibrechte, mit if(1) {...} ) jedoch wurde die CAD-Software auch dann nicht gestartet. Es liegt also nahe, dass etliche Systemaufrufe die danach folgen, oder was auch sonst immer, auch nicht funktionieren.
        Da sich daran seit jahren nichts geändert hat, kann es nur ein Windowsproblem sein.
        
        @Raubtier: comspec kann ich morgen auslesen.
        
        +5 replies
        
        Linuxer
        
        2015-01-21 23:13
        
        User since
        2006-01-27
        3890 Artikel
        HausmeisterIn
        
        Dann stellt sich genau die Frage, was sich an der Hälfte der Rechner geändert hat. Wenn es nicht die Rechner
        selbst sein sollen, dann evtl. an den Benutzerprofilen? Wurde evtl. irgendeine Sicherheitsrichtlinie aktiviert/verteilt, die eben die Umgebung der betroffenen Nutzer einschränkt/ändert?
        
        Ansonsten bliebe es halt übrig, die Umgebung der betroffenen Benutzer/Rechner zu kontrollieren; z.B. die Umgebungsvariablen mit Inhalt ausgeben:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8
        
        #! /usr/bin/perl use strict; use warnings; for my $k ( sort keys %ENV ) { print "$k = $ENV{$k}\n"; }
        
        Und in einer Datei abspeichern. Das macht man jeweils einmal an einem funktionierenden/nicht-funktionierenden Rechner und vergleicht dann die beiden Dateien miteinander.
        meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
        Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
        
        +4 replies
        
        tonewheel
        
        2015-01-22 12:39
        
        User since
        2006-10-01
        182 Artikel
        BenutzerIn
        
        Wollte nur informieren; seitens IT wurde eine Lösung gefunden. Warum diese funktioniert, ist allerdings nicht zu ermitteln. Das Script wird ja per Webseite aufgerufen. Da ich nicht weiß, wie das rechtlich ist, wenn ich Code poste, hier nur kleine, verfälschte Ausschnitte;
        
        Das hier ist der entsprechende Aufruf in der Original-Webseite, die per internem Server (Apache, IIS, oder sowas) bereit gestellt wird:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        <TR> <TD class=ms-vb-icon><IMG alt="......." src="page%20-%2.../bild.gif"></TD> <TD class=ms-vb2><A title="...foo...bar..." href="file:///X:/...pfad.../start.cmd"><NOBR>Name
        
        In der Start.cmd selbst wird nur der Pfad auf den Perlpfad erweitert und dann mit
        
        Code: (dl )
        
        perl scropt.pl
        
        aufgerufen.
        
        Sowohl aus der Webseite heraus, als auch durch direkten Start der start.cmd funktioniert das ganze nicht. Was aber funktioniert, ist eine Internetverknüpfung, die auf dem Desktop erstellt wurde:
        
        Code: (dl )
        
        1 2 3 4 5
        
        [{........-viele-Zahlen-....-............}] Prop3=19,9 [InternetShortcut] URL=file:///X:/...pfad.../start.cmd IDList=
        
        Wie schon erwähnt, dass es geht, kam wohl durch Zufall heraus. Aber warum diese Unterschiede bestehen, dazu auch noch auf nur einigen Rechnern, ist wirklich ein Rätsel.
        Oder haben lokal erstellte Verknüpfungen etwa andere Rechte/Variablen/Regeln aus Aufrufe aus dem Browser heraus? Falls ja, ist es immer noch fraglich, wieso der direkte Aufruf von start.cmd nicht funktioniert.
        
        +3 replies
        
        GwenDragon
        
        2015-01-22 12:45
        
        User since
        2005-01-17
        14746 Artikel
        Admin1
        
        Puuuuuh, das gehört in WebDevs Hall of Shame un die ITler gehören eher nach Admins Hell!
        Ach herrje, einmal Intranet, lokale Links, und der Webserver hat garantiert noch Einschränkungen, was externe Programme bei welchen Nutzern dürfen.
        Krude Intranetlösung.
        Es soll viele Leute geben, die glauben, man könne eben mal Datei-Links in Webseiten einbauen und die würden immer richtig geöffnet. Na ja, mit Word kann man auch sowas "programmieren".
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        +2 replies
        
        tonewheel
        
        2015-01-22 23:15
        
        User since
        2006-10-01
        182 Artikel
        BenutzerIn
        
        Hmmm, was soll ich dazu jetzt sagen...
        Den Webserver mal außen vor, finde ich schon eigenartig, dass es allein innerhalb der Shell schon solche Unterschiede gibt.
        
        GwenDragon
        
        2015-01-23 07:27
        
        User since
        2005-01-17
        14746 Artikel
        Admin1
        
        Man kann bei Windows wunder viel richtig administrieren und auch viel falsch, wenn man nicht weiß was man tut.
        
        Ich weiß nicht, welche Nutzer-,Datei- und andere Berechtigungen die Admins bei euch mit einer Policy (beim Installieren oder nachher) auf den Rechnern und dem Server gesetzt haben.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        tonewheel
        
        2015-01-22 23:19
        
        User since
        2006-10-01
        182 Artikel
        BenutzerIn
        
        Ja, sitzt auf:
        
        Code: (dl )
        
        C:\Windows\System32\cmd.exe
- GwenDragon
  
  2015-01-21 10:22
  
  User since
  2005-01-17
  14746 Artikel
  Admin1
  
  Verschoben von Sonstige Beiträge (auch Spaß und Sinnloses) nach Allgemeines zu Perl
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten

View all threads created 2015-01-20 23:11.