Newsgroup: it.comp.www.php
Titolo: path locali è path remoti

$path1='/a/b/c';
$path2='
http://a/b/c
';
$path3='
https://a/b/c
';
$path4='
ftp://a/b/c
';
$path5='ssh:/a/b/c';
 
Il primo path è locale, gli altri sono remoti.
Come faccio a distinguerli?
 
var_dump(false === strpos($pathX, ':'));
 
può andar bene o c'è un sistema più convenzionale?


A dire il vero solo il primo è un path, gli altri sono URI.
 
filter_var($path1, FILTER_VALIDATE_URL)
dovrebbe fare al caso tuo.
 
Ma a che ti serve?
 
Ciao!

dovrebbe fare al caso tuo.
 
Ho un'idea: perché non provare a implementare in PHP lo stesso algoritmo
usato dalla funzione parse_url() ? ;-D
 
Leonardo
 
-- 
 
Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

 
 
In realtà, da come è posto, il problema non è proprio risolvibile in teoria:
niente mi impedisce di avere una cartella chiamata "http:".
Per questo chiedevo che ci doveva mai fare.
 
Ciao!

 Ma a che ti serve?
 
se è un file (config.yml) apri l'url specificato in tale file con tanto 
di parametri; in caso contrario apri direttamene l'url.
Leonardo Serni avrà intuito cosa voglio fare, ricollegandosi ad u'altra 
mia discussione.

 mia discussione.
 
Non ho letto l'altra, per cui non so a cosa vi riferite :)
 
Ciao!

 Per questo chiedevo che ci doveva mai fare.
 
$ cat resource.yml
url: 
http://123/
 
params: a=1&b=2
 
Poi se vado nel browser e scrivo
 
http://test/?resource_to_test=resource.yml
 
 
un apposito script elabora il file yml, e alla fine carica la risorsa da 
testare
 
$res_to_test=file_get_content("
http://test/?a=1&b=2
");
 
Se invece digito
 
http://test/?resource_to_test=http://123
 
 
// non elaboro nessun file yml e carico direttamente la risorsa
$res_to_test=file_get_content("
http://123
");
 
Naturalmente 
http://123
 non ha bisogno di parametri aggiuntivi, 
altrimenti avrei dovuto usare il primo sistema.
 
Leonardo avrà intuito cosa voglio fare.


 
A me sembra un po' troppo arzigogolato per essere un caso reale: se mi
date il nome del thread ci butto un occhio.
 
Ciao!


verificare attivazione dell'error_prepend_string
il post delle 9.49 di ieri

 Non ho letto l'altra, per cui non so a cosa vi riferite :)
 
Mi sa che è meglio se la leggi :)


Sì, ora l'ho riletta e so anche perché non ho risposto :)
 
Quello che vuoi fare nell'altro thread è proprio sbagliato concettualmente:
non è compito del software che gira controllare se il sistema ha le
caratteristiche attese (eccezion fatta forse per le inizializzazioni di
codici mission-critical, ma sto divagando).
 
Quando installi la prima volta il tuo codice su un sistema, controlli
che quel sistema abbia le caratteristiche necessarie; se le ha, finita lì.
 
Se queste caratteristiche sono troppe o troppo esotiche ti fai uno script
di installazione, che oltre a copiare i files controlla pure il sistema.
 
Ciao!

codici mission-critical, ma sto divagando).
 
Che si gestiscono per quanto possibile con try/catch, aggiungo.


 
 
Mmhh mah, io direi di no :) Se hai una lista di controlli da fare, hai una
semplice sequenza di if, e fallisci con un report alla fine della
inizializzazione.
Come sopra, sempre che si debba fare, cosa che non accade quasi mai per
il normale ciclo di sviluppo software.
 
Ciao!

 che quel sistema abbia le caratteristiche necessarie; se le ha, finita lì.
 
Succede spesso che però certe impostazioni ritornano allo stato iniziale 
da un giorno all'altro...
Ma il 3d lo hai letto con attenzione?

 Ciao!
 
Non accade quasi mai... Beati i fortunati come te :D

 $path5='ssh:/a/b/c';
 
Quest'ultimo è sbagliato: "ssh://host/a/b/c"
 
Tutti gli URI hanno "://", puoi controllare quello.
 
Ma non è detto che siano remoti. Per esempio "file://" è locale.
 
E ce ne sono altri predefiniti (
http://php.net/manual/en/wrappers.php
) 
oltre a quelli che puoi definire da solo.
 
Credo dovresti ripensare quello che stai facendo.
 
Bye.

 Credo dovresti ripensare quello che stai facendo.
 
Effettivamente :)
 

il normale ciclo di sviluppo software.
 
Potrei avere entrambe le cose:
 
	try {
		controlli su mbstring
	} catch (\Exception $err) {
		...niente niente, non c'è il modulo multibyte?
	}
	// "Critical": qui devo arrivarci sano, o non arrivarci per niente
 
Il fatto è che sì, POTREI cavarmi di testa tutte le funzioni di cui ricordo
di aver bisogno e andare di foreach($miservono) if function_exists, però il
rischio di introdurre nuove funzioni senza ricordarmi di aggiornare il test
o che qualche admin diversamente lucido modifichi il config è tale che devo
comunque prevedere le eccezioni.
 
A questo punto una checklist di quel tipo mi diventa tripòde: una roba che,
per funzionare, ha bisogno di qualcos'altro... che però la rende superflua.
 
Quindi, tanto vale dar lievemente di piglio a try/catch, e alla via così.


 (verso la fine dell'articolo)
 
Qui stiamo parlando di PHP e di come gestisce i path (per esempio per 
file_get_contents), e il formato è quello dell'URI.
 
Quella che linki è una guida per la shell usando direttamente ssh (rsync 
usa direttamente ssh), quindi logicamente i suoi "path" saranno in un 
formato che non richiede "ssh://" davanti, ma direttamente "user@host:path".
 
Bye.
 

 "user@host:path".
 
OK ti do ragione anche su questo :)
Ma cosa avevano in testa gli sviluppatori dei protocolli su internet, a 
cosa gli serviva la doppia slash?

alex <1j94...@lnx159sneakemail.com.invalid> ha scritto:

comincia da qui:
 
https://tools.ietf.org/html/rfc3986
 
 
 


eppure anni fa ricordo di aver letto che il creatore di http, ha ammesso 
che era un impiccio che si poteva evitare, ma dato che ormai gli 
standard sono quelli...
 

 standard sono quelli...
 
http://forum.html.it/forum/showthread/t-1370452.html
 


Sì, l'ho letto, ma questo non l'avevo nemmeno preso in considerazione.
Se "certe impostazioni" ti cambiano senza che tu lo voglia ha ben altri
problemi di cui preoccuparti.
 
Ciao!

 problemi di cui preoccuparti.
 
Quindi mi stai dicendo che c'è una spiegazione sul perchè avvengano 
cambiamenti indesiderati?


C'è sempre una spiegazione: i computer non fanno le cose spontaneamente. Il
doverla scoprire (e correggere!) è appunto quel "ben altro problema" che ti
ritrovi.
 
(Io comincerei dal minacciare il sysadmin).


 (Io comincerei dal minacciare il sysadmin).
 
Prima di farlo userei prudenza (tanta), anche lui in fondo lavora con 
strumenti costruiti da alcuni soggetti di cui ho già accennato...


 
Sinceramente, non ho mai avuto problemi di questo tipo.
 
Ciao!

 Sinceramente, non ho mai avuto problemi di questo tipo.
 
Forse perchè il computer che usi è posizionato con lo schermo verso 
ovest, o che gli aggiornamenti non devono essere mai fatti di lunedì, 
martedì e venerdì. Quando si ha a che fare con la tecnologia tutto è 
possibile :)

Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?
 
Una possibilità è che tu abbia un php.ini vecchio stile (tutto in un file), e
lo stesso per Apache. La tendenza adesso è di avere un file .ini, con le cose
che devono stare sempre a quel modo, e un file ".local.ini", o similare, dove
ci metti le tue personalizzazioni. Di regola, se la stessa variabile si trova
in tutti e due, conta quella del file locale.


 in tutti e due, conta quella del file locale.
 
Ho fatto qualche prova.
 
$ cat index.php
<?php // index.php of 
http://usb-test.local/
 
echo "error_prepend_string: ".ini_get('error_prepend_string');
 
$ cat .user.ini
error_prepend_string = "test2"
 
$ curl 
http://usb-test.local/
 
error_prepend_string:
 
Non dovrebbe comparire 'test2'?

Non dovrebbe comparire 'test2'?
 
Perché il PHP di usb-test.local dovrebbe leggere un file chiamato ".user.ini"
nella home directory [1]?
 
Ancora ancora se fosse un .htaccess, e questo fosse attivato.
 
	php_value error_prepend_string 	"Settato localmente"
 
A proposito di .htaccess, una citazione dalla documentazione di Apache:
 
	In general, you should only use .htaccess files when you don’t have
	access to the main server configuration file.
 
	There is, for example, a common misconception that user authentication
	should always be done in .htaccess files, and, in more recent years,
	another misconception that mod_rewrite directives must go in .htaccess
	files. 
 
	This is simply not the case.
 
	You can put user authentication configurations in the main server
	configuration, and this is, in fact, the preferred way to do things.
 
Leonardo
 
[1] in teoria su Apache ci sarebbe la direttiva AccessFileName che... (pausa
    per spararsi in un piede) ...consentirebbe...


 
 
ok ok ok fermati :)

Oh ma questo sistema però funziona, molto bene :)
 
Finché .htaccess è attivo in quella directory, sì ;-)
 
Leonardo


 modulo Apache.
 
Cioè si può usare in altri modi?
Quante cose che non so, e più imparo più ho da imparare (beati gli 
ignoranti) :D

ignoranti) :D
 
Però, strada facendo ci si diverte, dài.


 Finché .htaccess è attivo in quella directory, sì ;-)
 
Perdona ancora la mia ignoranza, .htaccess in che modo si può disattivare?


Con una ricerca 
 
https://duckduckgo.com/?q=apache2+htaccess+disable&t=osx&ia=qa
 
 
È conveniente disabilitarli e mettere le impostazioni direttamente nel vhost del sito (Ubuntu) o apache2.conf (resto del mondo), perché Apache diventa più veloce.

 Del resto anche Apache mi pare abbia due "modalità", prefork e mpm.
 
Per precisione, il "framework" di moduli si chiama mpm, mentre i moduli 
possono essere prefork (lancia un pool di processi), worker (lancia un 
pool di processi, ognuno con un pool di thread) e event (ehm... boh! una 
sorta di green threads?)
 
PHP funziona solo con prefork, a meno di non compilarlo senza il 
supporto per i componenti che non sono thread-safe.
 
Bye.

 
 
Gli "event" nascono qualche anno fa appoggiandosi ad una nuova API di
kernel e glib (epoll), estendendo le possibilità della classica select().
Oggigiorno praticamente ogni software che classicamente faceva R/W su
fds/sockets in un ciclo con select è passato alla "nuova versione".
 
A livello di performances danno il massimo su alti numeri di richieste
statiche di basso carico, e infatti sono usati principalmente da webservers
lightweight tipo boa o, nel caso di apache, quando questo è il suo compito
principale.
 
Ciao!