12. marts 2003 - 17:10Der er
16 kommentarer og 1 løsning
Problem med generering af output i browser
Jeg har et problem med at få IE til at æde mit perl-script som kan ses på http://www.billeschou.net/rom2arab.txt - jeg har prøvet både med og uden formen på http://www.billeschou.net/roman.htm I begge tilfælde får jeg at vide at 'd:\home\billeschounet\www\rom2arab.pl' script produced no output. Da det er ligegyldigt om jeg går via min form eller ej, _må_ problemet ligge i mit perl-script. Jeg har ledt på nettet efter simple eksempler på hvordan man skaber samspil mellem forms og cgi/perl-scripts og fandt følgende: http://billeschou.net/input.htm - denne form kalder http://billeschou.net/navnOgFarve.txt Dette script virker glimrende og de ting der er med html tags osv. har jeg forsøgt at indføre i mit perl script med følgende resultater: http://www.billeschou.net/rom2arab2.txt og http://www.billeschou.net/rom2arab3.txt - lige lidt hjælper det. Det oprindelige script uden CGI-tilføjelser virker perfekt hvis jeg kører det fra en kommandoprompt. Så der må åbenbart mangle et eller andet for at få det til at spille med CGI. Please help!!!
Støv, fibre og metalliske partikler kan påvirke både uptime, levetid og driftssikkerhed. Derfor arbejder flere datacentre systematisk med contamination control.
Hvad sker der, hvis du kører rom2arab.txt fra kommandoprompten, altså versionen MED CGI-tilføjelserne? Hvad sker der, hvis du tilføjer 'use strict;' umiddelbart før 'use CGI;'?
version 2 skriver bare html tags'ene ud. Version 3 kommer med en brugerdefineret fejlbesked fordi der ikke er et tal at behandle (kommer som input fra den tilhørende form). Derudover skriver version 3 også html tags'ene ud. Når jeg bruger use strict får jeg en masse kompileringsfejl fordi scope ikke var defineret for mine variable. Efter at have rettet det, får jeg samme brugerdefinerede fejl som tidligere nævnt
Mere præcist kan jeg sige at jeg får følgende output når programmet køres fra prompten efter at have udkommenteret alle die og print-statements pånær 1. print convert2($q->param('roman')); 2. die "fejl! ved $param"; 3. print $@; (i sub convert2)
outputtet: fejl! ved at C:\rom2arab2-2.pl line 318. 1
Den første linie er den omtalte brugerdefinerede fejl (die "fejl! ved $param"; - i sub convert). 1-tallet har jeg ingen anelse om hvor kommer fra.
Du har ret, ignorér det med html tags i rom2arab2.txt. Ifølge AZero's hjemmeside er der CGI på deres webservere, så det vælger jeg at tro på ;)
Men altså, jeg er dybest set bare interesseret i at vide hvordan et perl-script skal være bygget op for at det leverer et output der kan fanges af en browser/behandles af cgi-fortolkeren. Der må være nogle generelle regler for den slags. Hvis det er tilfældet, må selvsamme regler kunne benyttes på mit script (hvis man opfatter det som en sort kasse). Eller er det helt forkert opfattet?
Mit spørgsmål gik mere på, om din udbyder har perl-modulet CGI installeret, det du får (burde få) fat i ved at skrive 'use CGI;'. Hvis din udbyder ikke har perl-modulet CGI installeret, vil dit program få kompileringsfejl allerede når der står 'use CGI;'. Dette kunne være årsagen til det manglende output.
Eksperiment: Prøv at skrive 'require CGI;' i stedet for 'use CGI;' - dette fører til at den først forsøger at loade CGI på kørselstidspunktet, altså efter kompileringen, hvis dette giver fejl burde det komme direkte i output.
Nu har jeg prøvet require CGI i stedet for, og jeg får stadig følgende besked når jeg trykker på "send" på formen: 'd:\home\billeschounet\www\rom2arab.pl' script produced no output. rom2arab.pl ligger i www folderen hos min udbyder - ligesom roman.htm (siden med den tilhørende form). Jeg synes det er meget underligt
Hmmm, udfra den information der er på http://www.azero.dk/support/programmering/perl/ at dømme, så er de mere interesserede i at man bruger php eller asp ("Vi anbefaler at man istedet for Perl anvender PHP eller ASP") og noget tyder på at der heller ikke er installeret nogle moduler ("Hvis du ønsker perl moduler eller pakker installeret kan dette muligvis lade sig gøre, og skal forespørges hos drift"). I så fald er der ikke noget at stille op... udover at lære php og konvertere programmet... øv ;)
Jeg har hos mig konstateret at udskriften 'efter require' udebliver, hvis jeg ændrer 'require CGI' til 'require CGIx' (som selvfølgelig ikke findes).
Du skal være klar over, at perl-modulet CGI blot er et hjælpe-modul til at gøre CGI-kodning i perl nemmere - det er ikke ubetinget nødvendigt. Du kan dog temmelig sikkert selv installere det på din hjemmeside, ved at finde CGI.PM hos dig selv lokalt og kopiere den til samme sted hos din udbyder, hvor resten af dine perl-scripts lever. Ovenstående kodestumper burde uden videre kunne teste, om det virker.
Glimrende tænkt Jesper. Den øverste udgave skriver kun "før require" ud. Den nederste skriver både "før require" og "efter require". Det vil vel altså sige at cgi.pm ikke er installeret på serveren... prøver lige at kopiere den over og se om det løser problemet
Nu har jeg rodet lidt rundt med at placere .pl-filen i et andet bibliotek, ændre stinavnet der peges på fra formen, kopiere cgi.pm over, lave en .htaccess fil (jvf. http://www.azero.dk/support/programmering/perl/mod_perl/) - de gange hvor der blev peget på et sted på serveren hvor .pl-filen ikke lå, meldte browseren at den ikke kunne finde filen. Ellers fik jeg blot at vide at mit script ikke leverer et output. Summa summarum har jeg installeret cgi.pm (vil jeg mene) på mit domæne (som ligger på en unixserver, så der skulle ikke være en perlkonflikt den vej rundt) og konstateret at browseren finder mit script og forsøger at afvikle det. Men derudover er jeg stadig på bar bund. Jeg må vist bide i det sure æble :( - du skal nu have stor tak for hjælpen jespernaur
Jeg er desværre ikke klar over, om cgi.pm kræver andre moduler for at kunne køre - dette kan måske forklare dele af dit problem. Det vil dog aldrig være browseren der har/ikke har et problem med at finde dit script. Det vil altid være serveren! Når der meldes at dit script ikke genererede noget output, er det serveren der brokker sig, ikke browseren. Det er også serveren, ikke browseren, der afvikler dit perl-script (hvis det ellers lykkes).
(Sakset fra azero's supportsider): FAQ Hvilke rettigheder skal mit CGI script have? Dit script skal kunne køres af 'verden' det vil sige det tredie tal skal give rettighed til at eksekvere scriptet. Dette gøre nemmeste ved at give dit script værdien 755.
Jeg har givet mit script værdien 777, hvorfor virker det ikke? Med værdien 777 har du givet 'verden' lov til at skrive i din fil, og dette sikkerhedshul gør at scriptet ikke kan køre. Giv højst 755 til dit script.
Jeg har givet et bibliotek værdien 777. Hvorfor virker mine CGI programmer ikke? Med værdien 777 har du givet 'verden' lov til at skrive og oprette filer i det pågældende bibliotek. Dette sikkerhedshul gør at CGI scriptet ikke kan køre. Giv højst 755 til biblioteket og skift til PHP hvis dit CGI script stadig ikke virker. -------------------------------- Jeg checkede dette op imod mine filer og de har alle 777 i rettigheder. Det er årsagen til mit problem må man gå ud fra. Begejstringen vil ingen ende tage når jeg forsøger at ændre det til 755 (via UltraEdit) og får at vide at jeg har ikke tilladelse til den operation.
Så noget tyder på, at man har den ensrettede mulighed for at tildele rettigheden 777, men ikke at komme tilbage til 755, er det sådan jeg skal forstå det du skriver? Hvad så med at slette filerne og genoprette dem med den behørige lave rettighed 755? (som man ikke kan komme ned på fra den højere rettighed 777)?
Det virker nu mest som om at de filer man uploader til serveren allesammen får rettighed 777 (svarer mig bekendt til default windows filrettighed). Det ville sådan set være ok hvis jeg havde mulighed for at ændre det fra min side. Desværre kan jeg ikke lige se hvordan jeg skulle kunne sætte den maske (som jo er unixspecifik) i windows.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
