addcslashes - replace php
¿Qué efecto tiene el punto-slash en PHP incluir llamadas? (7)
El punto-barra obliga al archivo a encontrarse solo en el directorio actual, en lugar de buscar las rutas mencionadas en la configuración include_path.
A. ¿Qué hace esto?
require ("./file.php");
B. en comparación con esto?
require ("file.php");
( No está en un directorio ... lo cual sería)
require ("../file.php");
Está nombrando explícitamente el directorio actual .
Hay una diferencia que noté hoy.
Digamos que incluye un archivo en index.php .
<?php
include "./inc/head.php";
// right now, with the current code, this would work as well:
// include "inc/head.php";
aclaración de tldr : es un poco más rápido usar " ./ " porque primero no buscaría en otras carpetas.
Pero ahora digamos que quiero incluir el archivo inc/functions.php .
Debido a que incluiré estas funciones en cada lugar que tenga la "cabeza", incluiría directamente ese archivo dentro de inc/head.php .
<?php
// Wouldn''t it be logical here to do this?
include "./functions.php";
El problema es que, dado que el archivo donde se inició el script es en realidad index.php y NOT inc/head.php , este script fallará porque trataría de buscar un archivo que no existe: un archivo llamado functions.php en el mismo directorio que index.php .
[+] inc/
/_ [.] functions.php <- We want to include this...
_ [.] head.php <- ...from this file
[.] index.php
x functions.php <-- Not this! (doesn''t exist)
Entonces, en lugar de usar el sintax "./", tenemos dos opciones:
- Incluya el archivo usando este código:
include "./inc/functions.php"; - Incluye el archivo usando este código:
include "functions.php"
Entonces, en este caso particular, tener o no un " ./ " en realidad es importante, ya que cambia considerablemente el comportamiento del script.
Espero que esto sea esclarecedor.
TLDR; El uso de "./" siempre será relativo al archivo donde las iniciales de ejecución, mientras se usa nada (""), será relativo al include_path, y después de eso, relativo al directorio del archivo actual
La primera versión obliga al mecanismo interno a incluir archivos relativos al ... archivo ejecutado directamente. Entonces, por ejemplo, tienes
index.php
// directly executed script (php -f index.php or from a browser)
include ''second.php'';
second.php
// This is included relatively to index.php
// Actually, it is first searched relatively to include_path, then relatively
// to index.php
include ''./third.php'';
Third.php
// This is included relatively to second.php ONLY. It does not search
// include_path
return "foo";
Simplemente le está diciendo a php que incluya el archivo en el directorio actual solamente o que falle si el archivo no está presente.
Si utiliza el formato "indexcommon3.php" y el archivo no está presente, php lo buscará en la variable de sistema include_path.
Para referencia, puede usar http://www.php.net/manual/en/function.include.php
./ es el directorio actual . Es en gran medida lo mismo que file.php , pero en muchos casos (este incluido) no comprueba ningún lugar estándar en que PHP pueda buscar un archivo, sino que solo verifica el directorio actual.
De la documentación de PHP (fíjate en la última oración):
Los archivos para incluir se buscan primero en cada entrada include_path relativa al directorio de trabajo actual, y luego en el directorio del script actual. Por ejemplo, si include_path es libraries, el directorio de trabajo actual es / www /, incluyó include / a.php y se incluye "b.php" en ese archivo, b.php se busca primero en / www / libraries / y luego en / www / include /. Si filename comienza con ./ o ../, solo se busca en el directorio de trabajo actual.
La respuesta corta
Tienes razón, no está en un directorio. A . se refiere al directorio en el que se encuentra, y ... se refiere al directorio principal.
Meaning, ./file.php y file.php son funcionalmente equivalentes en PHP. Aquí está la página de documentación relevante: http://us.php.net/manual/en/wrappers.file.php
La respuesta más larga
Sin embargo, solo porque funcionen igual en este contexto no significa que siempre sean iguales.
Cuando está operando en un entorno de shell * nix, y escribe el nombre de un archivo ejecutable, el shell buscará en los directorios PATH, pero no se verá en el CWD, o en el directorio en el que se encuentra actualmente.
Entonces, si estás en un directorio que tiene un archivo llamado: myprogram.php (este sería un archivo CLI de PHP) y simplemente escribes:
myprogram.php
no importa si tu programa es ejecutable o no. El shell se verá en / bin /, / usr / bin / etc para su archivo, pero no se verá en ./ ni en el directorio en el que se encuentre.
Para ejecutar ese programa sin agregar su directorio a la RUTA, necesita escribir
./myprogram
Entonces, realmente, ./ es más explícito. Significa que "el archivo que está buscando TIENE que estar aquí" y "no" significa "el archivo debe estar en algún lugar del programa buscando archivos".