Al definir una ruta a un directorio como variable o constante, ¿debería terminar con una barra inclinada? ¿Qué es la convención?
pwden Unix muestra su directorio actual sin una barra al final, mientras que la pestaña completa de cd /var/www/apps/incluye la barra al final, lo que me dejó inseguro.
Respuestas:
No incluyo la barra al final cuando, por ejemplo, defino un directorio para almacenar archivos. Eso es porque lo usaré como
$store_file = "$store_path/$file_id";
Siempre agregaré una barra diagonal antes de usar una variable que se supone debe contener una ruta de directorio. Creo que es mejor agregar siempre uno que preguntarse si se incluye la barra al final.
'///' + $root + '//' + $file + '/'y no importaría. Aunque tener la barra al final es una buena manera de discernir si la ruta es un archivo o un directorio, sería mejor agregar a las rutas como en '/' + $rootlugar de $root + '/'porque no puede estar seguro de que la ruta a la que se agrega tiene una barra al final , pero puede estar relativamente seguro de que varias barras se interpretarán como una sola barra en la mayoría de los entornos.
/tmp/store_data/sea un directorio, mientras que no está claro cuál es la misma ruta sin una barra diagonal/tmp/store_data
rm -rf $foo/$barpuede terminar enrm -rf /
Voy con la barra diagonal final porque:
"Si termina con una barra, es un directorio. Si no, es un archivo". es una convención fácil de recordar.
Al menos en los sistemas operativos que uso comúnmente, doblar la barra no causa problemas, mientras que omitir la barra causa grandes. Por lo tanto, es más seguro colocar la barra en la variable y usar "$ ruta / $ archivo" al hacer uso de ella.
A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.su mayor parte, se ha observado que las barras dobles generalmente se interpretan como una barra simple en implementaciones comunes.
Sé que esto tiene 10 años, pero quería arrojar mis muy obstinados $ 0.02.
No. No. Absolutamente no.
Estamos hablando de un sistema Unix. En referencia al directorio en sí, es un nodo como cualquier otro. Cuando se hace referencia al directorio, no debe nunca tener una barra sin escapar en su nombre (ref: dirname, pwd, ~, echo $HOME, echo $PATH, la salida de ls, et al).
Cuando se hace referencia a los contenidos de un directorio, a continuación, que necesita una barra. Es decir, ls /home/karl/es más apropiado que ls /home/karl(FTR, casi siempre hago esto último porque ... bueno, vago).
Cuando utilice una variable que contenga un directorio para crear la ruta completa a un archivo, siempre esperaría incluir la barra (i., E:) cp ${HOME}/test ${OTHER_DIR}/.
Se espera que un directorio no termine en una barra. Cualquier expectativa de que un directorio termine en una barra es incorrecta. Por lo tanto, agregar una barra al final del *_DIRvalor de una variable estaría subvirtiendo las expectativas.
En cuanto a la finalización de la pestaña, la expectativa aquí es que ingrese a ese directorio. Por lo tanto, la ayuda proporcionada por la finalización de la pestaña es llevarlo a ese directorio para que pueda tomar la siguiente elección en función de su contenido.
(referencia de los comentarios: Conceptos erróneos de Filepath , de la Talk:Path_(computing)página de Wikipedia . Gracias, john cj )
Vale la pena señalar que el hecho de que esté mal no significa que las herramientas / paquetes / bibliotecas nunca lo hagan. Es una ocurrencia demasiado común que tales cosas agreguen una barra al final cuando no debería existir. Por lo tanto, como sugirieron Bevan y Paul F , cuando se utilizan herramientas de terceros, es mejor eliminar las barras inclinadas que puedan existir en los nombres de los directorios.
Inodos de Unix
El inodo (nodo de índice) es una estructura de datos en un sistema de archivos de estilo Unix que describe un objeto del sistema de archivos como un archivo o un directorio.
- https://en.wikipedia.org/wiki/Inode
Estándar de jerarquía del sistema de archivos
El estándar para el sistema de archivos Unix (el Estándar de jerarquía del sistema de archivos, AKA FHS) muestra claramente que no se piensa que los directorios tengan una barra al final, sino que el contenido del directorio comienza con una barra (la única excepción a esto es /porque no nos referiremos a la raíz del sistema de archivos mediante el uso de una cadena vacía ... y uno nunca debería crear archivos allí de todos modos).
- http://www.pathname.com/fhs/pub/fhs-2.3.html
- https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
/que rompe el patrón. Y si tuviera que comenzar su razonamiento desde aquí (recursivamente), entonces puede llegar a las contradicciones que pueden estar en el corazón de las prácticas divergentes (como se evidencia en las respuestas aquí). Pero una vez que acepta esto como la excepción, todo lo demás encaja.
/., esto es sólo una idea terrible; Además de inyectar contenido muy inusual que conduce a problemas inesperados, parece simplemente tonto.
Sí, debería, como:
Nombre de ruta + nombre de archivo = ubicación de archivo completamente calificada.
Por lo tanto, la barra entre el último directorio y el nombre del archivo debe estar al final del nombre de la ruta o al principio del nombre del archivo. Prefijar los nombres de archivo con / significa que debe tener esto en cuenta si solo desea abrir un archivo (es decir, si asume que un nombre de archivo no calificado está en el directorio de trabajo actual).
Siempre que almaceno rutas de directorio o las devuelvo de las API, trato de seguir la convención de mantener una barra diagonal. Esto evita toda la ambigüedad de "si es un archivo o un directorio".
Anexo :
no pretende sustituir el uso de métodos que pueden tolerar una barra al final o su ausencia. Incluso usando esta convención, sigo usando Path.Combine(...)métodos similares.
os.path.join(dir, subdir_or_file)
Tal vez debería pensar en lo que significaría su decisión para los archivos. Si no incluye la barra al final del nombre de un directorio , tendrá que agregarla al principio del nombre del archivo .
Ahora, si por alguna razón, falta la ruta que conduce al archivo cuando concatenas cadenas, terminas con algo como /filenameque no es solo un archivo sino una ruta absoluta desde el directorio raíz (donde sea que esté en ese contexto) .
Es por eso que termino mis caminos con una barra y guardo los archivos como archivos.
./filename. Pero en general debería ser responsabilidad del código concatenar las rutas para hacerlo correctamente, y no hacer suposiciones de ninguna manera.
Sé que este es un hilo antiguo, pero pensé en compartir lo que hago. Si es posible, normalmente permitiría ambos y haría algo como esto (si fuera PHP):
$fullPath = rtrim($directory, '/') . '/filename.txt');
De esa manera, si el directorio está definido en un archivo de configuración, no importa si la próxima persona que lo cambie incluye la barra al final o no.
En php, dado que la función dirname (__ FILE __) devuelve el nombre del directorio sin una barra al final. Tiendo a ceñirme a esa convención.
De lo contrario, el uso de una barra al final de un nombre de directorio entrará en conflicto con la forma en que funciona dirname (..) y luego se quedará con el manejo de los dos casos ya que no sabe si el nombre del directorio proviene de un dirname (.. ) función o un contenido definido con una barra al final.
Conclusión: No use una barra inclinada al final ya que dirname (..) no lo hace.
// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!
Para otros idiomas, verifique la función que extrae un nombre de ruta y vea si está usando una barra al final o no, luego siga la convención del idioma.
Tiendo a agregar la barra diagonal final, ya que es más que probable que use ese directorio para agregar / recuperar archivos ...
En términos de referencia web, en realidad puede aumentar el rendimiento dejando la barra al final en
Nunca he visto una convención firme de ninguna manera.
Sin embargo, estoy bastante seguro de que lo que sea que decida, alguien más estará 100% seguro de que debería ser al revés. Entonces, la mejor idea es tolerar que las cosas se establezcan de cualquier manera.
En el mundo .NET, Path.Combine () le brinda una forma de manejar esto: hay equivalentes en otros entornos, desde archivos cmd en adelante.
Supongo que este es uno de esos raros casos en los que la respuesta correcta teórica y prácticamente es diferente.
Parece que la respuesta de @Karl Wilbur es correcta en un sentido teórico, ya que debería poder distinguir una referencia al nodo del directorio en sí del contenido del directorio.
Pero en la práctica argumentaré que la respuesta correcta es la opuesta:
La razón más importante es que puede decir con certeza que la ruta /home/FSObjectX/es una carpeta, mientras que /home/FSObjectXes ambigua. Nadie puede saber si este es un archivo de carpeta.
Las especificaciones siempre serán precisas y sin ambigüedades siempre que sea posible.
En la gran mayoría de los casos, siempre hará referencia al contenido de una carpeta, no al nodo dir en sí.
En esos raros casos en los que realmente lo hace, se puede manejar fácilmente en el código eliminando cualquier separador de directorios final opcional.
El uso de separadores de directorios dobles no hará ningún daño, aunque sin duda uno lo hará.
En teoría, es un mal argumento, ya que no debería codificarse por "casualidad", pero en la práctica, ocurren errores y tal vez el uso de dir-sep final podría terminar con algunos errores de tiempo de ejecución menos en un usuario final.
Al leer este interesante hilo, no he encontrado ninguna desventaja de usar dir-sep al final, solo que está mal en un sentido teórico. ¿O me perdí algo?