Problema Require

allora, il file che crea e il file creato si trovano nella stessa cartella, quel require lo uso in tutte le pagine del mio sito per non stare a ripetere tutte le volte il teg body e i pulsanti quindi i file ci sono...

[heracleum]

1) Innanzitutto rilassiamoci...
2) che hai un problema comunque, anche con il percorso corretto, è noto...
3) sto solo tentando di risparmiare altri due batti e ribatti tra te e webscript, che penserà lui ad aiutarti -ove possibile- quindi meglio agevolarlo, no?
4) quando webscript ti ha chiesto il file generato si aspettava un file con i percorsi corretti mentre si è visto quegli URL che non c'azzeccano nulla (almeno qui su AV con le sue impostazioni) ed era stato detto un po' da tutti
5) quindi per ora preparagli lo stesso .zip ma al posto di quegli URL e tantomento con percorsi tipo amehomepage.altervista.org/stile.php, è per il bene di tutti opportuno che tu scriva '../stile.php' e '../barra.php'

percorsi relativi solo perché così può testarlo -senza modificare il file- sulla sua macchina.

tutto qui.
Così torna webscript e si trova già bello e pronto un file coerente.

Se poi ho svalvolato pure io, amen! mi ritiro
ciaociao

si lo zip l' ho fatto 3 o 4 post fa c'è il link

[webscript]

allora, ora fermiamoci, concordo totalmente con heracleum... qua non si conclude niente... si sta solo andando avanti dicendo sempre le stesse cose...

Chiedo scusa se posso essere stato poco chiaro con questa frase... "http che persiste (togliendo l'url assoluto..)"... ho dimenticato i ... dopo l'http, però mi sembra che cmq il contenuto nelle parentesi avrebbe chiarito ognu dubbio anche con l'assenza dei puntini che stavano per "eccetera".

Allora facciamo un punto della situazione.

1)Questo file se tu lo apri, lo salvi senza aver toccato niente, e lo uploaddi sul server va... al contrario di quanto succederebbe se tenessi il file su AV senza salvarlo.

Ok, ora voglio vedere se succede anche a me questa cosa... quindi m'interesserebbe vedere questo file, e non dover per nessun motivo modificarlo.

Capisco che c'è il link... ma io vedo ancora quello vecchio che mi tocca modificare... io aggiornerei il link, anzi andrei sul sicuro mettendo la path assoluta detta precedentemente da heracleum.

Capisco che sia strano, lo è per tutti... anzi per molti è pura fantascienza... ma se ti da errore c'è un problema, non credo che il server modifichi le pagine che crei con uno script... non credi sia assurdo?
Quindi vorrei capire che ha il file che scarichi che non va... una cosa ancora più interessante sarebbe metterci anche lo script generatore... l'intero script, non solo il pezzettino cosi da poter testare anche quello.

Ripeto questa discussione poteva essere stata interrota parecchi post fa... appunto perchè è assurda la cosa a cui dobbiamo confrontarci... ed è per questo che le ipotesi sono le più assurde... ma anche se l'ipotesi fosse assurda, sarebbe bene provare a testare lo script e vedere se è "allergico" solo a te o a tutti. Però noi dobbiamo metterci nelle condizioni tue, cosa che ora mi vedo impossibilizzato visto che il zip mi indica ancora l'url assoluto.

WebScript

[binarysun]

Domanda (forse inutile, ma ha una logica):
il file tu l'hai scritto direttamente via web o l'hai fatto in locale e fatto l'upload??

prova a dichiarare la variabile tra gli apici enzichè le virgolette...

[webscript]

allora rispondo io per voi da quello che si è capito...

lui scrive tramite script una pagina php.

Dopo lui lo scarica dal server-pc il file generato... e guarda e nota che tutto è corretto... dopo lo salva senza modificarlo, lo auploadda e poi va...

Quindi non dovrebbe essere un problema del file del generatore, e poi se la stringa è scritta correttamente con le virgolette non ci son problemi.

Quindi bisogna vedere il tocco magico che lui fa sul pc... e se funziona anche agli altri...

È strana come cosa, l'abbiamo capito... e il problema si è esposto per pagine e pagine... concentrarsi sul fatto del tocco magico per capire che è una cosa insolita.

Quindi direi di concentrarsi sul tocco magico.. se no non si capisce più niente... il problema è stato esposto e le correzioni son state fatte tutte, (vedi heracleum)...

Non lo dico per fare il rompiscatole... ma per AmeHomePage... se no alla fine non capisce più niente...

Grazie mille così non ho dovuto ripertere il problema per la centesima volta...
ecco ho messo tutto lo script completo... http://amehomepage.altervista.org/poesie/new.zip

[webscript]

allora sentenza... Genero il file, (con path e tutto), da errore, lo downloaddo e senza modificarlo, ne toccarlo lo uploaddo, e miracolosamente va...

Altre info... quando scarico il file... la dimensione si dimezza da quella online... (in tutte le maniere, non centra niente il mio ftp).

Ora è l'ora di credere ai miracoli???

Heracleum, prova ma anche a me, non va, lo downloaddo e lo uploaddo senza toccarlo è va il file generato... bho!!!

Help all.

E' proprio un mistero... infatti se lo apri col pannello di controllo di av e lo salvi senza cambiare niente dopo funziona... l' unica spiegazione è che ci siano dei caratteri in più in quello generato dallo script (ma come fanno ad esserci se io non ce li ho messi??) mah... oppure il server ha problemi a interpretare certi script (non mi viene in mente un altra spiegazione)...

[heracleum]

No posso fare la prova in locale perché non ho MAI installato PHP sul mio pc, lavoro sempre via ftp su Altervista.

L'unica cosa che mi viene in mente e che voi -deduco- provate sempre in locale sul PC (Windows???) e NON VA,
lo uploadate su Altervista (UNIX) e va.
-se ho seguito bene-

Quindi mi viene da pensare immediatamente alla terminazione di righe di codice "\n"
a Windows piace \n\r mentre a UNIX basta \n..

In più noto che AmeHP oltre agli \n manda oltretutto A CAPO la stringa (no so perché io eviterei), cito un pezzetto:

$htm="
<html>\n
<head>\n
<title>\n
"

notate che dopo \n c'è anche un pericoloso INVIO.
Io eviterei uno dei due, fare due prove separate, una con solo \n e l'altra con solo INVII di stringa (propendendo per il buon esito del primo metodo, con \n): evito sempre perché il carattere "invio" che va a finire nella stringa mandandola a capo da codice dipende dal sistema in cui viene eseguito PHP..

Solo questo.. ma non avendo MAI usato PHP su Windows non so di preciso..
Se a voi va di fare questa prova ammetto che mi incuriosirebbe sapere i due esiti separati, se pensate che non valga a pena (perché magari mi è sfuggito qualcosa di ovvio) no problem
Ciao

no io l' ho sempre provato solo da AV (sul pc no ho il php installato) poi non so webscript se ha provato in locale o no

[webscript]

Heracleum mi sottovaluti:p

io ho provato ambedue, sia su server linux che windows.

L'interpretatore php... è quello, è indifferente il sistema operativo... ok?
Ora tirerete fuori la storia del case sensitive... si ma quello è il server non l'interpretatore... !

Quindi... è php che quando vede \n lo fa andare a capo, e Windows non centra proprio niente.

Chiarito questo... Una delle grandi funzionalità di php, è che non devi scrivere le funzioni, costrutti su una riga, e quindi puoi fare di tutto

echo "ci
a
o";

(naturalmente da ci a o perchè più spazi come output è uno se non s'interviene con CSS.)

Detto questo se tu fai un acapo, e come se facessi un \n, quindi se fai a capo e \n e come se andassi a capo due volte... ma non c'è nessun conflitto.

Ora provo a farlo con uno script il più vergine possibile... poi vi dico.

Ho provato con lo script vergine... la variabile htm conteneva semplicemente questo
$htm="<?\nrequire '/membri/webscript/stile.php';\nrequire '/membri/webscript/stile.php';\n?>";

(provato sia con path relativo che assoluto)
L'output è questo... e mi pare logico.
<?
require(...);
require(...);
?>

Eppure lo crea... su AV non va... salvo sul mio pc riuploaddo... e va... bho.

Curioso no? Insomma cosî lo script è proprio all'incipit... e non vedo errori di php.

[heracleum]

Uhmmm,...
non mi convince... non sono molto convinto che su sistemi op. diversi:

$var = "a \n b 
 c";

sia IDENTICO (a livello BINARY) a
$var = "a \n b \n c";

Secondo me su windows la prima versione (vedi blocco codice in alto)
equivale a:
$var = "a \n b \n\r c";

mentre su sistemi UNIX e simili dovrebbe equivalere a:
$var = "a \n b \n c";

Con "equivalere a" intendo che il FILE PHP che viene creato da script php avrà caratteri di fine riga con caratteri diversi.
Questo fin quando non entra in gioco un editor ASCII che di solito converte i caratteri di fine riga.

Dunque ok che hai provato sia su Linux che Windows..
Ma la domanda era: hai provato ad usare i vari terminatori con esiti diversi (o "\n\r" o "\n" o l'invio stringa)

Scusate se chiedo e non faccio prove dirette ma non trovo il tempo, sorry. :eyes:

[webscript]

Heracleum scusa se insisto...
È l'interprete php... non centra appunto niente l'OS...

in un sistema operativo è l'OS a interpretare \n\r... nel php è appunto l'interprete php, e appunto questo a niente a che fare con il sistema operativo...

WebScript

ti capisco per le prove... ma senti questa... quando scarico il download marca meno download... come se il server mi volesse mandare una pagina diversa.

È strano non lo metto in dubbio... ma ti dico lavoro sia su server linux che windows.

Io quà sto supponendo che è un problema solo di AV:..

Forse la risoluzione che ho pensato è una banalità però nn so se avete pensato anche a come viene salvato il formato dei file che viene generato.
Cioè mi spiego meglio: magari su AV si crea il file con estensione php ma nn si sa che di che formato(almeno io nn lo so) se ad es. file semplice di tipo text con estensione php o per esempio formato di codifica unicode.
Per cui magari viene generato il file su AV, questo nn va, si fa il download del file generato, si controlla con un editor di testo ma quando si chiude questo magari si salva con un formato(che in genere è di testo credo) che poi uploadato su AV funziona perchè magari con il salvataggio del file c'è questa riformattazione.
Nn so se questa potrebbe essere una risposta al problema, forse nn ha senso.

Forse un'altra risposta sta magari nella differenza sempre della codifica dei caratteri che però è diversa nei vari file php che vengono richiamati per cui salvandolo in locale e poi rimettendolo su AV va perchè come prima c'è un salvataggio del file che rende la codifica dei caratteri identica in tutta la pagina

[webscript]

il file non viene neppure aperto nelle ultime prove.

Cmq al momento del download il peso si dimezza... come se il server desse un altro file.

forse è sempre come penso un problema di codifica del testo, su server ha una codifica che lo rende + pesante mentre quando viene scaricato apache gli fa una conversione e lo rende più leggero

Non stai contando che io in locale non l' ho neanche scritto questo file ho fatto tutto dal server... infatti l' ho scaricato solo per fare lo zip...

ci sono due cose "strane" che si verificano

1- se si edita online il file generato dallo script, non è possibile salvarne le modifiche, in quanto l'ftp restituisce

COMMAND:>  STOR ty.php
STATUS:>     Connecting FTP data socket xxx.xxx.xxx.xxx:21402...
		   553 Impossibile aprire quel file: Permission denied
ERROR:>        Access denied.

2- l'unica cosa che cambia nello scaricare/ricaricare il file sullo spazio (pratica che sembra sbloccare il problema), sono i permessi chmod e l'owner del file...
mi spiego meglio: tutti i file creati su av (o trasferiti via ftp o pannello) sono chomoddati automaticamente a 664 e sempre con lo stesso owner (nel mio caso 52414). ora il file creato dallo script ha chmod 644 e un fantomatico owner 48. il download/reupload del file non fa altro che riportare 644->664 e 48->52414

sembra come se il meccanismo che chmodda tutte le cartelle e i file di AV "sorvoli" su quelli creati a runtime; naturalmente in locale i chmod rimangono quelli definiti dall'utente e non creano problemi

ora rimane da chiedersi... possono chmod e owner interferire sull'inclusione dei file?

















e che ne so io???
lo chiedo a Voi !! (magari ho solo sparato un sacco di "defecate"
forse Gianluca saprà chiarirci le idee...

mavericck

EDIT: per il punto 1 penso di aver capito che non posso salvare il file perchè non sono l'owner(48) ma 52414!

[heracleum]

Ho provato personalmente lo script generatore di php (direttamente su AV) e anche a me dà l'ormai consueto errore "Failed opening required ..."

MA
penso che a questo punto solo Gianluca può darci qualche delucidazione perché succede anche una cosa moolto strana:
se INSISTO a ricaricare il file php generato dallo script, perciò refresh su refresh, uno di fila all'altro ogni tanto FUNZIONA!! assurdo, il require funziona includendo il contenuto, con una frequenza casuale del tipo 1/10.

Altra cosa curiosa, proprio ieri stavo modificando gli attributi di permission (chmod) su dei file che genero via php (semplice testo però non php) e lo faccio tranquillamente da client FTP.. mentre su questi cacchio di file php generati da php il settaggio chmod mi fallisce?!?!?

[webscript]

Allora se il file è ancora su AV, il riuploaddamento continua a causare l'errore... se invece cancello il file su AV e poi lo riuploaddo va....

Quindi seguendo maverick... se il file è su AV mantiene lo stesso owner anche aggiornandolo...

ci sono due cose "strane" che si verificano
1- se si edita online il file generato dallo script, non è possibile salvarne le modifiche, in quanto l'ftp restituisce

COMMAND:>  STOR ty.php
STATUS:>     Connecting FTP data socket xxx.xxx.xxx.xxx:21402...
		   553 Impossibile aprire quel file: Permission denied
ERROR:>        Access denied.

Invece io (sempre dal server perchè, ripeto, non programmo mai in php in locale) riesco tranquillamente ad editare il file generato e salvarne le modifiche... (sarà perchè l'ho creato io?)
Aspetto il verdetto di Gianluca...

[Gianluca]

ora rimane da chiedersi... possono chmod e owner interferire sull'inclusione dei file?

Certamente, e poi lo script crea un file con maschera 0644 e uid Apache, pertanto quel file è di sola lettura per l'uid dell'account.

Per questo motivo è sconsigliabile far creare degli scripts php agli scripts php stessi, il discorso di heracleum va approfondito, ma credo sia correlata alle politiche di caching che il phpengine fa sul codice incluso nei require, probabilmente cambiando il nome del file incluso (e quindi modificando anche lo script includente) il fenomeno dovrebbe sparire.

Invece io (sempre dal server perchè, ripeto, non programmo mai in php in locale) riesco tranquillamente ad editare il file generato e salvarne le modifiche... (sarà perchè l'ho creato io?)
Aspetto il verdetto di Gianluca...

per editarlo on-line ho usato cuteftp o lo stesso zend studio, può darsi che tu usi il pannello per eseguire le modifiche

mavericck

[heracleum]

Certamente, e poi lo script crea un file con maschera 0644 e uid Apache, pertanto quel file è di sola lettura per l'uid dell'account.

Ok, infatti anche nella mia prova (il più possibile fedele a quella di AmeHP) al php generato risulta chmod 644.. Anche se poi non capisco all'interprete che gli importa la protezione da scrittura per un include.. o forse sfrutta i valori solo dal punto di vista di security e permessi (in effetti a quello servono) e non "fisicamente" per la manipolazione del file stesso (?).

Comunque a me per "quella recente modifica" al mio script che saturava la processlist mysql, accade invece che mi crea i file con 664! forse perché li creo in una cartella anch'essa generata dallo script? (almeno nella mia ignoranza sono arrivato a questa facile deduzione, poi.. chiedo appunto) solo un numero di file limitatissimo (tipo 20 su 1000) hanno il 644, e non capisco perché (beata ignoranza).
EDIT: no ma che dico??? mi rimangio tutto le cartelle le ho create con il mio client FTP.

Per questo motivo è sconsigliabile far creare degli scripts php agli scripts php stessi, il discorso di heracleum va approfondito, ma credo sia correlata alle politiche di caching che il phpengine fa sul codice incluso nei require, probabilmente cambiando il nome del file incluso (e quindi modificando anche lo script includente) il fenomeno dovrebbe sparire.

Ah sì vero, possibilissssimo, visto tra l'altro che -sempre per seguire fedelmente le prove di AmeHP- il file php generato dallo script tentava di includere (require) un file che era stato appena esplicitamente -e a buon fine ovviamente- incluso nello script php generatore, come appunto fa Ame.

Scusate il lungo periodo di attesa ma sono stato presissimo con la scuola... ho provato a rinominare i file del require ma continua a non funzionare..

[Gianluca]

I files inclusi sono stati creati dallo script php stesso?

no i file stile.php e barra.php li ho fatti io con l' editor di Av