Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21787 > unrolled thread

path locali è path remoti

Back to article view | Back to it.comp.www.php

Contents

  path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 17:56 +0100
    Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 09:34 -0800
      Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-22 19:39 +0100
        Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 10:58 -0800
          Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 21:48 +0100
            Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 13:00 -0800
              Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 22:27 +0100
      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 21:27 +0100
        Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 12:49 -0800
          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 22:32 +0100
            Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 15:08 -0800
              Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-23 00:19 +0100
                Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 15:30 -0800
                  Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 09:36 +0100
                  Re: path locali c path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-23 14:41 +0100
              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 09:32 +0100
                Re: path locali è path remoti fmassei@gmail.com - 2017-11-26 17:26 -0800
                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-27 18:09 +0100
                    Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-27 19:16 +0100
                      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-28 15:16 +0100
                        Re: path locali è path remoti fmassei@gmail.com - 2017-11-28 07:35 -0800
                          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-28 17:34 +0100
                        Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-28 23:48 +0100
                          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-29 11:02 +0100
                            Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-29 14:32 +0100
                              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-29 15:27 +0100
                                Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-29 17:50 +0100
                                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-30 13:28 +0100
                                    Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-30 16:11 +0100
                                      Re: path locali � path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-30 17:10 +0000
                                        Re: path locali � path remoti fmassei@gmail.com - 2017-12-04 18:22 -0800
                                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-30 17:18 +0100
                                    Re: path locali è path remoti fmigliori <fmigliori@gmail.com> - 2017-11-30 08:41 -0800
    Re: path locali è path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-23 11:25 +0000
      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 13:32 +0100
        Re: path locali è path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-23 14:38 +0000
          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 16:18 +0100
            Re: path locali è path remoti "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-11-24 17:59 +0000
              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-25 12:18 +0100
                Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-25 12:49 +0100

Page 1 of 2  [1] 2  Next page →

#21787 — 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?

[toc] | [next] | [standalone]

#21788

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!

[toc] | [prev] | [next] | [standalone]

#21789

On Wed, 22 Nov 2017 09:34:53 -0800 (PST), fmassei@gmail.com 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

-- 

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.

[toc] | [prev] | [next] | [standalone]

#21790 — Re: path locali č path remoti

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@gmail.com 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
> 

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!

[toc] | [prev] | [next] | [standalone]

#21793 — Re: path locali č path remoti

Il 22/11/2017 19:58, fmassei@gmail.com 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: 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.

[toc] | [prev] | [next] | [standalone]

#21794 — Re: path locali č path remoti

On Wednesday, November 22, 2017 at 3:50:57 PM UTC-5, alex wrote:
> Il 22/11/2017 19:58, fmassei@gmail.com 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!

[toc] | [prev] | [next] | [standalone]

#21795 — Re: path locali č path remoti

Il 22/11/2017 22:00, fmassei@gmail.com ha scritto:
> On Wednesday, November 22, 2017 at 3:50:57 PM UTC-5, alex wrote:
>> Il 22/11/2017 19:58, fmassei@gmail.com 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!
>

verificare attivazione dell'error_prepend_string
il post delle 9.49 di ieri

[toc] | [prev] | [next] | [standalone]

#21791

Il 22/11/2017 18:34, fmassei@gmail.com ha scritto:
> 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.
>

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.

[toc] | [prev] | [next] | [standalone]

#21792

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!

[toc] | [prev] | [next] | [standalone]

#21796

Il 22/11/2017 21:49, fmassei@gmail.com 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 :)

[toc] | [prev] | [next] | [standalone]

#21797

On Wednesday, November 22, 2017 at 4:34:30 PM UTC-5, alex wrote:
> Il 22/11/2017 21:49, fmassei@gmail.com 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!

[toc] | [prev] | [next] | [standalone]

#21798

On Wed, 22 Nov 2017 15:08:26 -0800 (PST), fmassei@gmail.com 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

-- 

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.

[toc] | [prev] | [next] | [standalone]

#21799 — Re: path locali č path remoti

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@gmail.com 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!

[toc] | [prev] | [next] | [standalone]

#21801 — Re: path locali č path remoti

Il 23/11/2017 00:30, fmassei@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#21804 — Re: path locali c path remoti

On Wed, 22 Nov 2017 15:30:38 -0800 (PST), fmassei@gmail.com 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

...non è una "inizializzazione di codice mission critical" :-)

E' più una checklist di installazione, che come giustamente dici:

>Come sopra, sempre che si debba fare, cosa che non accade quasi mai per
>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ì.

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.

[toc] | [prev] | [next] | [standalone]

#21800

Il 23/11/2017 00:08, fmassei@gmail.com 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?

[toc] | [prev] | [next] | [standalone]

#21811

On Thursday, November 23, 2017 at 3:35:02 AM UTC-5, alex wrote:
> Il 23/11/2017 00:08, fmassei@gmail.com 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?
>

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!

[toc] | [prev] | [next] | [standalone]

#21812

Il 27/11/2017 02:26, fmassei@gmail.com ha scritto:
> 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.

Quindi mi stai dicendo che c'è una spiegazione sul perchè avvengano 
cambiamenti indesiderati?

[toc] | [prev] | [next] | [standalone]

#21813

On Mon, 27 Nov 2017 18:09:35 +0100, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Il 27/11/2017 02:26, fmassei@gmail.com ha scritto:
>> 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.

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

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.

[toc] | [prev] | [next] | [standalone]

#21814

Il 27/11/2017 19:16, Leonardo Serni ha scritto:
> C'è sempre una spiegazione: i computer non fanno le cose spontaneamente. Il
> doverla scoprire (e correggere!) è appunto quel "ben altro problema" che ti
> ritrovi.
> 

Non è che per caso anche gli sviluppatori di apache, php, mysql e 
componenti relativi, abbiano qualcosa da scoprire e sistemare come si deve?
Qualche spiegazione la vorrei piuttosto da loro...

$ sudo apt-get install apache2 phpX my-sql

e si dovrebbero aggiornare i vari software, ma senza alterare i file di 
configurazione (php.ini, ecc.).
Questi devono stare come gli ho impostati inizialmente. PUNTO

Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web