[PHP] Include relatief aan huidig bestand (C++ style)

[Olaf van der Spek]

PHP:

require_once('common.php');

Ik wil een bestand relatief ten opzichte van het huidige bestand includen, onafhankelijk van de current working directory, het include path en de directory van het 'root' script (dat wordt aangeroepen door de browser).

Dit lijkt echter absoluut niet mogelijk.
Ik kan geen manier vinden om achter de volledige bestandsnaam van het huidige bestand te komen.

Is er iemand die hier een fatsoenlijke oplossing voor heeft?

quote: http://nl2.php.net/manual/en/function.include.php

Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script. E.g. if your include_path is ., current working directory is /www/, you included include/a.php and there is include "b.php" in that file, b.php is first looked in /www/ and then in /www/include/. If filename begins with ./ or ../, it is looked only in include_path relative to the current working directory.

[ Voor 3% gewijzigd door Olaf van der Spek op 14-04-2006 13:39 ]

[Peter]

PHP:

require_once( dirname( __FILE__ ) . '/common.php' );

zoiets?

[djluc]

De meeste frameworks in PHP bieden hier functies voor aan. Zo heb je in Typo3 iets als: extPath('extensionName') wat automatisch het volledige path genereert naar de module. Dit wordt gedaan omdat er op de verschillende platforms waarop PHP draait verschillende paden zijn, dat kan je dan allemaal in die functies afvangen.

[Olaf van der Spek]

.Peter schreef op vrijdag 14 april 2006 @ 13:40:

PHP:

require_once( dirname( __FILE__ ) . '/common.php' );

zoiets?

Inderdaad.
Ik had het net ook zelf gevonden: http://bugs.php.net/bug.php?id=30881
Ik snap niet dat PHP zo eigenwijs is op dit gebied.

[Erkens]

OlafvdSpek schreef op vrijdag 14 april 2006 @ 13:45:
Ik snap niet dat PHP zo eigenwijs is op dit gebied.

nee, jij begrijpt gewoon niet wat include doet
PHP != C++

maar ehm, als jij die "bug" in 2004 al gepost hebt, waarom weet je dat nu niet meer dan en open je dit topic

[ZroBioNe]

Dit gebruik ik altijd:

PHP:

$path = '/home/zrobione/public_html/www/test/abc/';

set_include_path(get_include_path() . PATH_SEPARATOR . $path);
require_once('includes/global.inc.php');
unset($path);

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 13:49:
nee, jij begrijpt gewoon niet wat include doet
PHP != C++

Dan ben ik benieuwd in welke situatie het handig(er) is om includes ten opzichte van de current working directory te gebruiken.

maar ehm, als jij die "bug" in 2004 al gepost hebt, waarom weet je dat nu niet meer dan en open je dit topic

Ik kon me vaag iets van een workaround herinneren maar ik was __FILE__ vergeten en probeerde $_SERVER['SCRIPT_NAME']. Het duurde ook even voordat ik die bug weer gevonden had en daarvoor had ik dit topic al gepost: race condition.

[ Voor 3% gewijzigd door Olaf van der Spek op 14-04-2006 13:55 ]

[Erkens]

OlafvdSpek schreef op vrijdag 14 april 2006 @ 13:55:
Dan ben ik benieuwd in welke situatie het handig(er) is om includes ten opzichte van de current working directory te gebruiken.

Bijna elke situatie, je include immers een file in een andere waardoor deze in feite dezelfde file is.
Het is ook veel logischer om files te includen vanuit de werk directory gezien, omdat je immers daar aan het werk bent en niet ergens anders. Ik zou wel eens willen weten wanneer het (met PHP) beter is om vanuit de directory van je file te werken, vaak heb je dan een slechte directory structuur bedacht.

Met C(++) heb je nog de header files waarvan het _wel_ logisch is om die in dezelfde directory te hebben, maar voor de rest is het onzinnig.

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 14:00:
Bijna elke situatie, je include immers een file in een andere waardoor deze in feite dezelfde file is.
Het is ook veel logischer om files te includen vanuit de werk directory gezien, omdat je immers daar aan het werk bent en niet ergens anders. Ik zou wel eens willen weten wanneer het (met PHP) beter is om vanuit de directory van je file te werken, vaak heb je dan een slechte directory structuur bedacht.

Wat bedoel je met werk directory? De directory van het script dat de browser aanroept?

[Erkens]

OlafvdSpek schreef op vrijdag 14 april 2006 @ 14:02:
[...]

Wat bedoel je met werk directory? De directory van het script dat de browser aanroept?

ja natuurlijk, de werkdirectory veranderd toch niet met een include (tenzij je een chdir gebruikt natuurlijk) aangezien je gewoon een fopen doet en die file inleest.

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 14:05:
ja natuurlijk, de werkdirectory veranderd toch niet met een include (tenzij je een chdir gebruikt natuurlijk) aangezien je gewoon een fopen doet en die file inleest.

Nee, maar dan neem je aan dat de cwd gelijk is aan de directory van het root script, wat bijvoorbeeld bij CLI niet het geval is.
Ook neem je dan aan dat chdir nergens in de code gebruikt wordt, aangezien dan al je includes de mist in gaan.

Maar ok, dan zijn dus al je includes ten opzichte van het root script. Dat betekent dus dat je geen van die bestanden kunt includen vanuit een andere directory?

[.oisyn]

Ik heb dat altijd al een idiote beslissing van PHP gevonden. Natuurlijk werk je wél met files in een directory, je hebt bijvoorbeeld een bepaalde module opgesplitst in meerdere files en die in een aparte directory gezet. De algemene interface die je include vanuit je hoofdscript staat in één van die files, het is dan niet logisch om vanuit die interface-file weer bestanden relatief aan het script zelf te gaan includen. Je weet immers niet vanuit welke directory je interface wordt geinclude, en dus moet de huidige directory voor je include directives gelijk zijn aan die van de huidige file. Anders krijg je gewoon een ontzettend onwerkbare situatie op het moment dat je met verschillende directories gaat werken.

[ Voor 12% gewijzigd door .oisyn op 14-04-2006 14:31 ]

[NMe]

Met .oisyn. Deze domme "feature" heeft me in het verleden nogal wat kopzorgen veroorzaakt, voordat ik eraan dacht dat __FILE__ toepasbaar was. Een aantal van de eerdere sites die ik gemaakt heb hadden daarom een compleet platte directorystructuur en ik probeerde me maar te behelpen door met de extensies te spelen.

Als ik bestand B vanuit bestand A wil includen, en bestand B heeft afhankelijkheden van bestand C, dan wil ik dat die referentie naar bestand C blijft kloppen, en niet dat er ineens vreemde errors gaan optreden terwijl bestand B prima werkt wanneer het niet geïnclude wordt...

[Erkens]

OlafvdSpek schreef op vrijdag 14 april 2006 @ 14:07:
Nee, maar dan neem je aan dat de cwd gelijk is aan de directory van het root script, wat bijvoorbeeld bij CLI niet het geval is.

volgens mij begrijp je niet wat een werkdirectory is
de werkdirectory is _niet_ de directory waar het "root script" staat, maar de directory waar je bent op het moment dat je de applicatie uitvoerd. Nu heb je wel gelijk dat deze werkdirectory gelijk is met de directory van het script, maar dat komt doordat de webserver dat doet

Ook neem je dan aan dat chdir nergens in de code gebruikt wordt, aangezien dan al je includes de mist in gaan.

chdir moet je dan ook niet gebruiken
Maar eingelijk doe je al wat fout als je niet gebruik maakt van include_path.

Maar ok, dan zijn dus al je includes ten opzichte van het root script. Dat betekent dus dat je geen van die bestanden kunt includen vanuit een andere directory?

include_path of die dirname( __FILE__ )

[NMe]

Erkens schreef op vrijdag 14 april 2006 @ 14:55:
include_path of die dirname( __FILE__ )

En dat vind je serieus makkelijker/logischer dan de manier waarop het in C/C++ en tientallen andere talen is aangepakt?

[Erkens]

-NMe- schreef op vrijdag 14 april 2006 @ 15:05:
[...]

En dat vind je serieus makkelijker/logischer dan de manier waarop het in C/C++ en tientallen andere talen is aangepakt?

makkelijker niet, logischer wel

[Janoz]

Ik denk dat jij uberhaupt de eerste persoon bent die ik tegenkom die het daadwerkelijk handig vindt dat de code die je in 1 bestand schrijft compleet afhankelijk is van de locatie binnen het filesysteem waarop deze geinclude wordt. Misschien is het een idee om eens met een andere taal iets te gaan doen? Ik heb het idee dat veel van je php-verdedigingen puur gebaseerd zijn op een gebrek aan ervaring met een omgeving waarin andere ontwerp beslissingen zijn genomen.

Op dit moment moet ik allemaal workarounds maken omdat ik dezelfde includes in de root gebruik als in een admin subdirectory.

[ Voor 3% gewijzigd door Janoz op 14-04-2006 15:31 ]

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 14:55:
volgens mij begrijp je niet wat een werkdirectory is

Ik dacht het wel.

de werkdirectory is _niet_ de directory waar het "root script" staat, maar de directory waar je bent op het moment dat je de applicatie uitvoerd. Nu heb je wel gelijk dat deze werkdirectory gelijk is met de directory van het script, maar dat komt doordat de webserver dat doet

Inderdaad.

chdir moet je dan ook niet gebruiken

Ah, nog zo'n nuttige PHP feature.

Maar eingelijk doe je al wat fout als je niet gebruik maakt van include_path.

Maar waar is jouw scenario nou waarin het handig is dat include afhangt van de directory van het root script of van de current working directory?

[T-MOB]

Ik weet niet of het aan mij ligt, maar ik heb hier nog nooit een probleem mee gehad. Onderstaande functioneert iig gewoon (wat overigens ook in overeenstemming is met de quote uit de TS).

PHP:

#foo.php
require_once 'bar/init.php';

#bar/init.php
require_once 'test.php';

#bar/test.php
echo 'Hello World';

t-mob@klara:~$ php /var/www/includetest/foo.php
Hello World
t-mob@klara:~$ curl 127.0.0.1/includetest/foo
Hello World
t-mob@klara:~$

[Erkens]

Janoz schreef op vrijdag 14 april 2006 @ 15:31:
Ik denk dat jij uberhaupt de eerste persoon bent die ik tegenkom die het daadwerkelijk handig vindt dat de code die je in 1 bestand schrijft compleet afhankelijk is van de locatie binnen het filesysteem waarop deze geinclude wordt.

Je leest niet goed.

Misschien is het een idee om eens met een andere taal iets te gaan doen?Ik heb het idee dat veel van je php-verdedigingen puur gebaseerd zijn op een gebrek aan ervaring met een omgeving waarin andere ontwerp beslissingen zijn genomen.

En waar komt die flame vandaan? Ik ken en gebruik zat andere talen, mij hoef je echt de verschillen niet uit te leggen.
Jij weet niet wat ik voor werk doe, dus waar je vandaan haalt dat ik geen ervaring heb met dergeljike omgevingen is mij totaal onduidelijk. Verder vraag ik me af waarom het nodig is om zo op de man te spelen Juist iemand met zo'n rode jas moet beter weten...

Op dit moment moet ik allemaal workarounds maken omdat ik dezelfde includes in de root gebruik als in een admin subdirectory.

Waaruit al weer blijkt dat er niet nagedacht is over de directory structuur

OlafvdSpek schreef op vrijdag 14 april 2006 @ 15:35:
Ah, nog zo'n nuttige PHP feature.

Nee, het kan handig zijn om chdir te gebruiken, juist met CLI applicaties

[ Voor 9% gewijzigd door Erkens op 14-04-2006 15:42 ]

[Soultaker]

Wat is daar nu logisch aan

Sowieso is die include_path ongeschikt. Als je nu twee verschillende modules gebruikt die eenzelfde bestand delen (denk aan veelvoorkomende dingen als 'db.php' of 'login.php') en die voegen allebei hun basedir aan de include_path toe, dan includet de tweede module de bestanden van de eerste met dezelfde naam.

Kortom, dat hele include-path gebeuren is gewoon fundamenteel stuk en relatieve includes zijn dat niet. De hack met dirname(__FILE__) werkt, maar is niet meer dan een hack om een relatieve include te simuleren.

[Olaf van der Spek]

T-MOB schreef op vrijdag 14 april 2006 @ 15:39:
Ik weet niet of het aan mij ligt, maar ik heb hier nog nooit een probleem mee gehad. Onderstaande functioneert iig gewoon (wat overigens ook in overeenstemming is met de quote uit de TS).

En zet voor de grap nu eens ook een test.php een directory hoger. Welke test.php include bar/init.php dan?

[Soultaker]

T-MOB schreef op vrijdag 14 april 2006 @ 15:39:
Ik weet niet of het aan mij ligt, maar ik heb hier nog nooit een probleem mee gehad. Onderstaande functioneert iig gewoon (wat overigens ook in overeenstemming is met de quote uit de TS).

PHP:

#foo.php
require_once 'bar/init.php';

#bar/init.php
require_once 'test.php';

#bar/test.php
echo 'Hello World';

t-mob@klara:~$ php /var/www/includetest/foo.php
Hello World
t-mob@klara:~$ curl 127.0.0.1/includetest/foo
Hello World
t-mob@klara:~$

Dat werkt toevallig omdat je én '.' in je includepath hebt staan én er staan geen bestanden met dezelfde naam in de current working directory. Als je in je homedir ook een test.php hebt staan, wordt die aangeroepen. Dat kan natuurlijk nooit de bedoeling zijn geweest van het oorspronkelijke script!

Kortom: de werking van je script is afhankelijk van de working directory van waaruit je 'm aanroept zelfs als je helemaal niets met bestanden of directories doet. Dat is gewoon een design flaw, zeker aangezien dit niet duidelijk is (zoals je al zegt: als je die code van jou gewoon test merk je nergens aan dat 'ie fundamenteel kapot is).

[ Voor 19% gewijzigd door Soultaker op 14-04-2006 15:49 ]

[Janoz]

Och, het is heel simpel:

ik heb een libA.php en een libB.php. libA is afhankelijk van libB. Beide bestanden staan in de dir libs. In een normale logische omgeving zou je dan in libA aangeven dat hij libB nodig heeft. Vervolgens heb je twee pagina's. Een index.php en ook een index.php in de directory admin. Nu kun je dus niet meer zomaar libA gebruiken! Zou je libA includen in de index dan zou in libA moeten staan dat hij libs/libB.php moet includen. Zou je dezelfde lib ook nog in de admin/index.php gebruiken dan moet er ineens ../libs/libB.php moeten staan.

[T-MOB]

Soultaker schreef op vrijdag 14 april 2006 @ 15:46:
Kortom: de werking van je script is afhankelijk van de working directory van waaruit je 'm aanroept zelfs als je helemaal niets met bestanden of directories doet. Dat is gewoon een design flaw, zeker aangezien dit niet duidelijk is (zoals je al zegt: als je die code van jou gewoon test merk je nergens aan dat 'ie fundamenteel kapot is).

Ah, ok, dat is een duidelijk verhaal. Alhoewel ik er in de praktijk nog nooit een probleem mee ondervonden heb. In het vervolg maar even rekening mee houden dus

[.oisyn]

Erkens schreef op vrijdag 14 april 2006 @ 15:39:
Waaruit al weer blijkt dat er niet nagedacht is over de directory structuur

Over de directory-structuur is voldoende nagedacht, alleen PHP gaat daar niet fijn mee om. Wat jij nu zegt is dat je er niet goed over na hebt gedacht omdat PHP er niet echt handig mee omgaat, dan draai je de zaak imho gewoon om. Het is van den zotte dat de werking van je script afhankelijk is van de directory vanwaar hij wordt geinclude, terwijl het script zelf niet anders is.

Je C++ argument eerder in deze draad vind ik ook onzin, de relatie header->sourcefile is helemaal niet door de taal vastgelegd, dat is gewoon een handige manier om ermee te werken. Je zou het ook op de PHP manier kunnen doen, een hoofd-cpp file die alle overige cpp files include. Eveneens zou je alle functies en classes als inlines in een header kunnen zetten, ook dit komt overeen met hoe PHP werkt. Maar dat breekt allemaal nogal op het moment dat PHP's manier van includen wordt gebruikt, op dezelfde manier zoals het nu de scripts van de topicstarter breekt.

Wat de relevantie van je working dir met include directives te maken hebben ontgaat me een beetje, wat is daar nou in hemelsnaam het nut van . Je working dir is voor het lezen en schrijven van files, includen heeft daar niets mee te maken, en als je dat wel afhankelijk van je working dir wilt maken (wat zelden voorkomt) kun je vrij gemakkelijk de huidige directory opvragen en die gebruiken voor je include directive.

[ Voor 51% gewijzigd door .oisyn op 14-04-2006 16:40 ]

[Erkens]

Nee jij vergelijkt een script met een compiled applicatie, immers als jij files inlaad in je C applicatie dan gaan die ook uit van de werkdirectory
Overigens vraag ik me het nut van deze discussie af. Als de taal en of de eigenschappen niet je niet liggen dan gebruik je toch wat anders?

[.oisyn]

Erkens schreef op vrijdag 14 april 2006 @ 16:40:
Nee jij vergelijkt een script met een compiled applicatie, immers als jij files inlaad in je C applicatie dan gaan die ook uit van de werkdirectory

Nee hoor, de directory waarvandaan je de compiler aanroept heeft geen zak te maken met waar de include files vandaan worden gehaald.

En waarom is het hier relevant of het al dan niet gecompileerd wordt? Waarom zou je die PHP file niet kunnen compilen/preprocessen zodat die include directives niet meer aanwezig zijn? (flauw antwoord: omdat het afhankelijk is van de runtime working dir)

Ik heb nog altijd geen goed argument gehoord waarom die afhankelijkheid van de directory van het aanroepende script wél nuttig is. En als je de discussie niet nuttig vind moet je er gewoon niet aan meedoen

[ Voor 42% gewijzigd door .oisyn op 14-04-2006 16:44 ]

[NMe]

Erkens schreef op vrijdag 14 april 2006 @ 16:40:
Nee jij vergelijkt een script met een compiled applicatie, immers als jij files inlaad in je C applicatie dan gaan die ook uit van de werkdirectory

Ja, en als je files inleest vanaf PHP ook. Je vergelijkt nu appels met peren. Het gaat hier om het includen van bestanden, wat geen functie is, maar het gebruik van taalelementen. Include in PHP is functioneel gezien hetzelfde als een include precompiler directive in C en is daarom wèl te vergelijken. Voor het openen van files heeft PHP fopen en die mag van mij best relatief zijn aan de werkdirectory. Includes niet, dat levert alleen gezeur op. Het feit dat je eigenlijk altijd hacks moet gebruiken om eromheen te werken zegt genoeg.

Overigens vraag ik me het nut van deze discussie af. Als de taal en of de eigenschappen niet je niet liggen dan gebruik je toch wat anders?

Mag er dan in zijn geheel niet gesproken worden over de zwakke punten van een taal? Want ja, die heeft PHP. Als er niet over gediscussiëerd wordt, dan zal er ook nooit een verbetering in de taal doorgevoerd worden.

[Erkens]

.oisyn schreef op vrijdag 14 april 2006 @ 16:41:
En waarom is het hier relevant of het al dan niet gecompileerd wordt? Waarom zou je die PHP file niet kunnen compilen/preprocessen zodat die include directives niet meer aanwezig zijn? (flauw antwoord: omdat het afhankelijk is van de runtime working dir)

PHP include die file niet bij het preprocessen maar op het moment van de instructie, zo kan je bijvoorbeeld dynamisch een bepaalde file includen

Je kan de PHP include niet vergelijken met de #include van C. include van PHP heeft immers ook gewoon een return value.

-NMe- schreef op vrijdag 14 april 2006 @ 16:44:
Mag er dan in zijn geheel niet gesproken worden over de zwakke punten van een taal? Want ja, die heeft PHP. Als er niet over gediscussiëerd wordt, dan zal er ook nooit een verbetering in de taal doorgevoerd worden.

Natuurlijk kan er over gediscussieerd worden, maar je komt toch nooit tot een conclusie met dit soort dingen, daarnaast gok ik dat mocht er ooit een conclusie komen dat dit niet wordt teruggekoppeld naar PHP

[ Voor 30% gewijzigd door Erkens op 14-04-2006 16:52 ]

[.oisyn]

Duh, álles wordt in PHP pas bij het uitvoeren geevalueerd. Maar dat wil nog niet zeggen dat het op de huidige manier logisch is (dat is, de dir van het caller heeft voorrang op de dir van de callee). Je blijft nu alleen maar hameren op het feit dat het anders is, ja, dat is inmiddels wel duidelijk, maar geen argument dat het include gedeelte ook anders werkt (PHP zou namelijk prima kunnen werken met de C/C++ logica van include directories). Argumenten waarom dat dan handig is ontbreken nog altijd, terwijl tegenargumenten waarom dat niet handig is al volop zijn gegeven in deze draad.

[ Voor 26% gewijzigd door .oisyn op 14-04-2006 16:56 ]

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 16:40:
Overigens vraag ik me het nut van deze discussie af. Als de taal en of de eigenschappen niet je niet liggen dan gebruik je toch wat anders?

Het nut is het vinden van een antwoord op de vraag "Maar waar is jouw scenario nou waarin het handig is dat include afhangt van de directory van het root script of van de current working directory?"

[.oisyn]

Tja, die afhankelijkheid van de current working dir vind ik bij nader inzien een beetje een loose cannon en komt natuurlijk door het feit dat je een . in het includepath hebt staan en dat ze pas @ runtime geevalueerd worden. Desalniettemin had het wel handig geweest als ze naast de . een manier hadden om de dir van het root script in het includepath op te nemen.

[ Voor 24% gewijzigd door .oisyn op 14-04-2006 17:00 ]

[Erkens]

.oisyn schreef op vrijdag 14 april 2006 @ 16:54:
Duh, álles wordt in PHP pas bij het uitvoeren geevalueerd. Maar dat wil nog niet zeggen dat het op de huidige manier logisch is (dat is, de dir van het caller heeft voorrang op de dir van de callee). Je blijft nu alleen maar hameren op het feit dat het anders is, ja, dat is inmiddels wel duidelijk, maar geen argument dat het include gedeelte ook anders werkt (PHP zou namelijk prima kunnen werken met de C/C++ logica van include directories). Argumenten waarom dat dan handig is ontbreken nog altijd, terwijl tegenargumenten waarom dat niet handig is al volop zijn gegeven in deze draad.

Zo duidelijk dat het anders is, is het blijkbaar niet.
include in PHP is niks anders dan een fopen en een eval als je het simpel bekijkt, niet een "echte" include zoals je die van gecompileerde talen kent.
Immers je kan nooit van te voren weten welke files er geinclude moeten worden, dat wordt tijdens de utivoer bepaald, kan je het mee eens zijn of niet, het werkt nu eenmaal zo.
Overigens is het "probleem" wat jullie ervan maken eenvoudig op te lossen door . in je include_path te zetten, wat doorgaands ook een standaard setting is.

edit:
ah, je hebt het eindelijk door zie ik

[ Voor 4% gewijzigd door Erkens op 14-04-2006 17:04 ]

[Janoz]

Zoals Soultaker al aangaf is het toevoegen van de . in je include_path nog niet de juiste oplossing. Enkel een workaround hack die in bijna alle gevallen het probleem verdoeselt.

[Erkens]

Janoz schreef op vrijdag 14 april 2006 @ 17:44:
Zoals Soultaker al aangaf is het toevoegen van de . in je include_path nog niet de juiste oplossing. Enkel een workaround hack die in bijna alle gevallen het probleem verdoeselt.

ehm, je maakt er zelf een probleem van door te denken dat die include hetzelfde is als een include in een andere taal
Ik vraag me af waarom de . in include_path plaatsen een "workaround hack" is? Het is gewoon de manier om te doen wat je wilt. En dubbele filenames moet je gewoon voorkomen, dat is _nooit_ handig

[.oisyn]

Erkens schreef op vrijdag 14 april 2006 @ 17:03:

edit:
ah, je hebt het eindelijk door zie ik

Nee je leest niet goed.

[Olaf van der Spek]

.oisyn schreef op vrijdag 14 april 2006 @ 16:58:
Desalniettemin had het wel handig geweest als ze naast de . een manier hadden om de dir van het root script in het includepath op te nemen.

Waarom zou je dat willen doen?
Met root script bedoel ik het script dat de browser aanroept, niet het script waar de include in staat.

Erkens schreef op vrijdag 14 april 2006 @ 17:48:
ehm, je maakt er zelf een probleem van door te denken dat die include hetzelfde is als een include in een andere taal
Ik vraag me af waarom de . in include_path plaatsen een "workaround hack" is? Het is gewoon de manier om te doen wat je wilt. En dubbele filenames moet je gewoon voorkomen, dat is _nooit_ handig

Omdat het bijvoorbeeld niet werkt als je PHP CLI gebruikt. En omdat het dan eerst gaat kijken relatief van het root script en dan pas relatief van het current script.

En: "Maar waar is jouw scenario nou waarin het handig is dat include afhangt van de directory van het root script of van de current working directory?"

[ Voor 7% gewijzigd door Olaf van der Spek op 14-04-2006 18:13 ]

[.oisyn]

OlafvdSpek schreef op vrijdag 14 april 2006 @ 18:13:
[...]

Waarom zou je dat willen doen?
Met root script bedoel ik het script dat de browser aanroept, niet het script waar de include in staat.

Dat bedoelde ik ook, waar het me om ging is dat je files wilt includen relatief aan die directory. Maar ik zat niet goed na te denken, want dat wordt al gecovered door de huidige-script-dir .

Maar nogmaals, die . in je include path is hier natuurlijk helemaal niet de issue, de issue is dat de caller dir voorrang heeft op de callee dir.

[Erkens]

.oisyn schreef op vrijdag 14 april 2006 @ 18:20:
Maar nogmaals, die . in je include path is hier natuurlijk helemaal niet de issue, de issue is dat de caller dir voorrang heeft op de callee dir.

nee, niet de caller dir maar de werkdir, dat is zo geregeld vanuit het OS, eenzelfde "probleem" zou je immers ook hebben met bijvoorbeeld een bash script

[Olaf van der Spek]

Erkens schreef op vrijdag 14 april 2006 @ 18:48:
nee, niet de caller dir maar de werkdir, dat is zo geregeld vanuit het OS, eenzelfde "probleem" zou je immers ook hebben met bijvoorbeeld een bash script

Dit heeft niks met het OS te maken. PHP kiest ervoor de current working directory te gebruiken.

Als je geen antwoord wil geven op mijn vraag mag je dat ook zeggen, maar dan heeft verdere discussie inderdaad weinig nut.

[ Voor 17% gewijzigd door Olaf van der Spek op 14-04-2006 19:15 ]

[NMe]

Erkens schreef op vrijdag 14 april 2006 @ 18:48:
nee, niet de caller dir maar de werkdir, dat is zo geregeld vanuit het OS, eenzelfde "probleem" zou je immers ook hebben met bijvoorbeeld een bash script

Dus het is wèl de caller. De working directory is altijd gelijk aan de directory waar het bestand op het laagste niveau van de include-hiërarchie staat.

En ik vraag me af waarom je nou al een stuk of vier keer de directe vraag die aan jou persoonlijk gesteld wordt uit de weg gaat: wanneer is het handig om include op deze manier te laten werken?

[Janoz]

Erkens schreef op vrijdag 14 april 2006 @ 17:48:
[...]

ehm, je maakt er zelf een probleem van door te denken dat die include hetzelfde is als een include in een andere taal

Zo te zien ben jij eerder de enige die er geen probleem van maakt.

Ik vraag me af waarom de . in include_path plaatsen een "workaround hack" is? Het is gewoon de manier om te doen wat je wilt.

Wat ik wil is dat de scope van mijn probleem binnen mijn bestand blijft of wordt bepaald door de bestanden die ik daarin include. Dat houdt alles overzichtelijk. Ik wil niet dat de werking afhankelijk wordt van de manier van includen in het bestand dat mijn lib gebruikt en op welke positie dit bestand staat tov mijn lib.

En dubbele filenames moet je gewoon voorkomen, dat is _nooit_ handig

Jij bent zeker ook groot tegenstander van namespaces?


Geef 1 steekhoudend voorbeeld waarin deze ontwerpbeslissing handiger is.

[djc]

Dit probleem valt natuurlijk ook op te lossen door je scripts uit te voeren via een enkel "dispatch"-bestand, dat vervolgens het eigenlijke script include. Je kunt dan door je hele applicatie heen includen vanuit de gedachte dat je in je dispatch-script.

Niet echt een directe oplossing voor je probleem, though, gewoon maar € 0.02.

[NMe]

@Manuzhai: dat is inderdaad een oplossing, maar dat houdt op als je moet werken met een aangeleverde library of als je zelf een library schrijft.

[Olaf van der Spek]

Manuzhai schreef op vrijdag 14 april 2006 @ 19:58:
Dit probleem valt natuurlijk ook op te lossen door je scripts uit te voeren via een enkel "dispatch"-bestand, dat vervolgens het eigenlijke script include. Je kunt dan door je hele applicatie heen includen vanuit de gedachte dat je in je dispatch-script.

Behalve, natuurlijk, als het een CLI app is.
Of als je zo'n dispatch bestand zowel in vhost 1 als 2 wilt hebben zonder de hele app code te dupliceren.