Problem med eAccelerator + encoding

<ole>

De viste stier er jo i hvertfald helt hen i skoven. Der, hvor de dannes, skal du lede efter fejlen  =)

/mvh
</bole>

Der er intet galt med stierne. Som jeg skriver så går eksempel 2 fint, og der er stien magen til eksempel 1

Hvis man vil være påståelig, er det en fordel at være 100% sikker! Det _er_ stierne, den er helt gal med .... kik dog på dem  =)

Hint: '\\' kontra '/'  ;o)

Stierne er bare noget output, og har INTET med mit problem at gøre....

Når jeg nu fortæller dig at de to eksempler (eller filer) ligger samme sted, og det kun er indholdet af filen der er afgørende for om encoding fejler eller går godt.

Prøv at se bort fra at stierne der tumbede ud, og kig på det jeg spørger om.

Ja, det er netop output ... output, hvor PHP fortæller dig, hvad der ikke kan lade sig gøre:

    ERROR: Can't compile file
    "C:\\Program Files\\xampp\\htdocs\\hh/enctest.php"

Nej, det tror da pokker den ikke kan kompilere en fil med en sti, der er en bastard mellem to forskellige styresystemers måde at skrive en sti på!

PHP må ikke kunne behandle - endsige finde - en fil med denne sti:
    "C:\\Program Files\\xampp\\htdocs\\hh/enctest.php"

- og derfor giver det absolut ingen mening at se bort fra 'at stierne der tumbede ud'  =)

Lige et eksempel Ole.... Hvis stierne ovenfor er så meget i skoven virker nedenstående vel ikke?

<?php
$file = "c:\\tmp/olebole.txt";
file_put_contents($file, 'Er der mon fejl i dette????');
?>

Og en lille en mere... Fejlen kommer ikke fra PHP, men fra eAccelerator (encoder.php linie 44)

Mærkeligt, du beder om hjælp, og får svar på hvad det er. Men du vil ikke tro på det. Så er det svært!
Det ER stierne der er forkerte.

Nu bruger windows godt nok \ men altså ikke \\ , hvilket er hvad de andre har prøvet at fortælle dig.

Jeg vil så bare tilføje at eAccelerator ikke ligefrem har det bedste php5 support, så du vil nok bruge Zend Encoder hvis du absolut SKAL lave security by obscurity.

tdafoobar >> Nej, det er nu ikke det, jeg prøvede at fortælle ham. Da '\' jo skal escapes i PHP, skal der stå '\\' - men jeg er til gengæld ret sikker på, han ikke kan mixe de to ('\' og '/') i samme sti. Under alle omstændigheder ville enhver koder ved sine fulde fem rette det med det samme  ;o)

Jeg gover Ole ret i at det ville være rart hvis stierne var pænere, men som sagt er det ikke det der er mit problem, og jeg gider ikke begynde at rette eAccelerator koden for at få noget pænt output.

Problemet i en nøddeskal

Kompilering af denne fil går godt:
<?php
$q = "SELECT * FROM table WHERE id = 3";
?>

Kompilering af denne fil går IKKE godt:
<?php
$id = 3;
$q = "SELECT something FROM table WHERE id = ".$id;
?>

Dvs. problemet opstår når jeg forsøger at lave streng konkatering med variable. Da dette jo er en rimelig simpel operation gætter jeg på at problemet må være et sted i min opsætning. Kan vi være enige om at det er underligt at jeg kan encode den første, men ikke den anden fil?

$q = "SELECT something FROM table WHERE id = '".$id."'";  ;o)

- og så bør man jo også altid escape navne i SQL-kald ... ikke mindst, hvis man kan finde på at kalde dem noget reserveret  ;o)
    $q = "SELECT `something` FROM `table` WHERE `id` = '".$id."'";  ;o)

$q = "SELECT something FROM table WHERE id = '".$id."'";  ;o)

Dette gør ingen forskel. Jeg havde forsøgt denne mulighed, selvom det ikke er nødvendigt når id er en int. (Dette havde jeg selvfølgelig ikke skrevet nogle steder). Jeg kan faktisk godt få min kode til at kompilere når jeg gør følgende:

<?php
$id = 3;
$q = sprintf("SELECT something FROM table WHERE id = %d", $id);
?>

Men det er rimelig surt at skulle skrive hele koden om til at bruge sprintf istedet for streng konkatering.

Jeg har dog fundet en anden løsning jeg kan bruge, som virker fint. PHPs bcompiler extension, som desværre er experimental, men den virker.

Hvis nogen vil have nogle point er i velkomne til at svare. Jeg skal ikke bruge dem.

Generelt tak for hjælpen, selvom i ikke er meget for at tro på min sti-historie :-)

luk