Schrift
[thread]669[/thread]

CGI-Verzeichnis auf FAT32: Zentrales CGI-dir auf dual boot



<< >> 4 Einträge, 1 Seite
mättu
 2006-02-12 16:55
#6883 #6883
User since
2004-12-12
30 Artikel
BenutzerIn
[default_avatar]
Hallo Freunde des Perl
:-)

Nachdem ich heute bereits lange an meinem Verstand gezweifelt hatte, bin ich jetzt auf die Lösung gekommen. Weil ich auf diesem Forum herumgesucht habe und viel in die Richtung, nicht aber die Lösung gefunden habe, hier mein Erlebnisbericht:

Ausgangslage:
- Dual-Boot PC Windows XP / Ubuntu - Linux
- Verzeichnis mit Arbeitsdaten auf FAT32, damit es beide Systeme lesen & schreiben können.
- Apache2-Webserver mit auf beiden Systemen sollen auf selbes Verzeichnis zugreifen.
- Funktioniert auf Windows

Problem:
- CGI-Perl-Skripte auf der FAT32 erzeugen auf Linux im Apache immer einen 500er-Fehler. "Premature end of script headers"
- Error-Log redet von "permission denied"
- Kopiert man das Script in den Standard-CGI-Ordner, geht es
- Lässt man das Script auf der Konsole laufen, geht es auch.

Fehler:
Man denkt:
- Es hat entweder mit der Apache-Konfiguration zu tun
- Oder mit dem Perl-Script
- Oder mit der Zeichenkodierung der Partition
- Oder mit dem Texteditor von Windows
- oder...

Dann hört man auf zu denken und haut den Kopf an die Wand.

Lösung:
- HD muss mit Option "exec" gemountet werden.

Bsp:
/etc/fstab:
/dev/hda2 /media/hda2 vfat rw,auto,user,exec,fmask=0000,dmask=0000 0 0

Glaubt mir Freunde, ich hab mir in die Stirn gebissen. Wie kann man nur so doof sein.
Allerdings bin ich damit nicht ganz allein. Wenn man so im Internet herumsucht..

Wenn ein Script immmer nicht läuft, hängt es *vielleicht* auch damit zusammen, dass Linux eine andere Kodierung für Zeilenumbrüche hat als Windows. Also muss man das liebe File im Linux öffnen, nach der #!-Zeile ein Enter einfügen und es läuft.
Auch darüber kann der Laie lange, lange nachdenken.

Und die #!-Zeile muss korrekt sein. Das fällt einem nicht auf unter Windows, weil sie dort wegen der abgefeimten registry-Anweisung des Apache völlig unnötig ist.

So. Jetzt wirds mir aber langsam zu peinlich. ;-)

Hoffe jedenfalls, es hilft anderen armen Seelen weiter. Klarklar, ihr Experten findet das alles logisch. Aber nicht jeder kann ein ganzes Informatikstudium absolvieren, nur um ein wenig einen apache lokal zu fahren.
Von Perl oder perl oder pERL oder PeRl gar nicht zu reden.
Da blick einer durch.

Grüsse
:m)\n\n

<!--EDIT|mättu|1139756164-->
renee
 2006-02-13 00:21
#6884 #6884
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Danke für den ausführlichen Bericht. Ich habe es mal ins Wiki aufgenommen...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
ptk
 2006-02-13 01:41
#6885 #6885
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Die Erklärung ist einfach. Wenn man unter Windows editiert, sieht die Shebang-Zeile so aus:
Code: (dl )
#!/usr/bin/perl\r\n

Linux/Unix wertet die Zeichenkette zwischen #! und \n aus, um den zu ausführenden Befehl zu erhalten:
Code: (dl )
/usr/bin/perl\r
. Dieser Befehl wird ausgeführt - geht natürlich nicht, existiert ja auch nicht (aber der interessierte Benutzer kann ja eine Kopie von "perl" als "perl\r" anlegen, dann sollte es funktionieren). Die einfachste Lösung: irgendeine Option an den perl-Pfad anhängen, z.B. -w. Dann kriegt das Betriebssystem /usr/bin/perl mit, der Rest wird an Perl übergeben, und Perl scheint kein Problem mit \r zu haben.
nepos
 2006-02-13 09:56
#6886 #6886
User since
2005-08-17
1420 Artikel
BenutzerIn
[Homepage] [default_avatar]
Oder halt einfach mit einem Editor arbeiten, der diese Dateien mit fuer Unix korrekten Zeilenumbruechen versieht. Das sollten die meisten guten eigentlich koennen.
<< >> 4 Einträge, 1 Seite



View all threads created 2006-02-12 16:55.