faretesto > comp.www.* > comp.www.php

alex (22.11.2017, 18:56)
$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?
fmassei (22.11.2017, 19:34)
On Wednesday, November 22, 2017 at 11:57:39 AM UTC-5, alex wrote:
> $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!
Leonardo Serni (22.11.2017, 20:39)
On Wed, 22 Nov 2017 09:34:53 -0800 (PST), fmassei wrote:

>> $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.


Ho un'idea: perché non provare a implementare in PHP lo stesso algoritmo
usato dalla funzione parse_url() ? ;-D

Leonardo
fmassei (22.11.2017, 20:58)
On Wednesday, November 22, 2017 at 1:39:21 PM UTC-5, Leonardo Serni wrote:
> On Wed, 22 Nov 2017 09:34:53 -0800 (PST), fmassei wrote:
> Ho un'idea: perché non provare a implementare in PHP lo stesso algoritmo
> usato dalla funzione parse_url() ? ;-D


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!
alex (22.11.2017, 22:27)
Il 22/11/2017 18:34, fmassei ha scritto:
> On Wednesday, November 22, 2017 at 11:57:39 AM UTC-5, alex wrote:
> A dire il vero solo il primo è un path, gli altri sono URI.


In generale cmq sono nomi di risorse.

> filter_var($path1, FILTER_VALIDATE_URL)
> dovrebbe fare al caso tuo.
> 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.
alex (22.11.2017, 22:48)
Il 22/11/2017 19:58, fmassei ha scritto:
> In realtà, da come è posto, il problema non è proprio risolvibile in teoria:
> niente mi impedisce di avere una cartella chiamata "http:".


Ahi anche questo è vero, comunque proseguiamo...

> Per questo chiedevo che ci doveva mai fare.


$ cat resource.yml
url:
params: a=1&b=2

Poi se vado nel browser e scrivo



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



// non elaboro nessun file yml e carico direttamente la risorsa
$res_to_test=file_get_content("http://123");

Naturalmente non ha bisogno di parametri aggiuntivi,
altrimenti avrei dovuto usare il primo sistema.

Leonardo avrà intuito cosa voglio fare.
fmassei (22.11.2017, 22:49)
On Wednesday, November 22, 2017 at 3:29:22 PM UTC-5, alex wrote:
> se è un file (config.yml) apri l'url specificato in tale file con tanto
> di parametri; in caso contrario apri direttamene l'url.


Se usi le funzioni di PHP mi semra siano tutte transparenti.
Per il caso specifico passi a yaml_parse() il ritorno di una
file_get_contents() e non importa dove sia la risorsa, dovrebbe funzionare
in tutti i cinque casi da te citati.

> Leonardo Serni avrà intuito cosa voglio fare, ricollegandosi ad u'altra
> mia discussione.


Non ho letto l'altra, per cui non so a cosa vi riferite :)

Ciao!
fmassei (22.11.2017, 23:00)
On Wednesday, November 22, 2017 at 3:50:57 PM UTC-5, alex wrote:
> Il 22/11/2017 19:58, fmassei ha scritto:
> > Per questo chiedevo che ci doveva mai fare.

> <snip>
> 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!
alex (22.11.2017, 23:27)
Il 22/11/2017 22:00, fmassei ha scritto:
> On Wednesday, November 22, 2017 at 3:50:57 PM UTC-5, alex wrote:
> 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
alex (22.11.2017, 23:32)
Il 22/11/2017 21:49, fmassei ha scritto:
> Se usi le funzioni di PHP mi semra siano tutte transparenti.
> Per il caso specifico passi a yaml_parse() il ritorno di una
> file_get_contents() e non importa dove sia la risorsa, dovrebbe funzionare
> in tutti i cinque casi da te citati.


X-)

>> Leonardo Serni avrà intuito cosa voglio fare, ricollegandosi ad u'altra
>> mia discussione.

> Non ho letto l'altra, per cui non so a cosa vi riferite :)


Mi sa che è meglio se la leggi :)
fmassei (23.11.2017, 01:08)
On Wednesday, November 22, 2017 at 4:34:30 PM UTC-5, alex wrote:
> Il 22/11/2017 21:49, fmassei ha scritto:
> > 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!
Leonardo Serni (23.11.2017, 01:19)
On Wed, 22 Nov 2017 15:08:26 -0800 (PST), fmassei wrote:

>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).


Che si gestiscono per quanto possibile con try/catch, aggiungo.

Leonardo
fmassei (23.11.2017, 01:30)
On Wednesday, November 22, 2017 at 6:19:50 PM UTC-5, Leonardo Serni wrote:
> On Wed, 22 Nov 2017 15:08:26 -0800 (PST), fmassei wrote:
> >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).

> 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!
alex (23.11.2017, 10:32)
Il 23/11/2017 00:08, fmassei ha scritto:
> Quando installi la prima volta il tuo codice su un sistema, controlli
> 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?
alex (23.11.2017, 10:36)
Il 23/11/2017 00:30, fmassei ha scritto:
> 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!


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

Discussioni simili