¿Debo usar una barra oblicua al final de las variables de ruta en el script de shell o no? [cerrado]


11

Hoy cuando escribo mi script de shell.

Una pregunta de repente viene a mi mente.

Desde cd /target_diry cd /target_dir/ambas obras.
¿Debo agregar una barra diagonal al final de mis variables de ruta en un script de shell?
Tal como LOG_PATH=/data/nginx/logsversus LOG_PATH=/data/nginx/logs/.

Hice una búsqueda general en google, pero no encontré discusión sobre esto, ¿tal vez es demasiado básico?

Por ahora, es realmente difícil para mí decidir qué estilo elegir.
Pero preferí el LOG_PATH=/target_dir/estilo un poco más.
Porque cuando estoy haciendo autocompletar con bash, me muestra el resultado con una barra diagonal.

¿Cuál es tu opinión sobre esto, por qué?



No hay regla Ambos estilos de codificación tienen algunas ventajas y algunos inconvenientes.
andcoz

Respuestas:


8

De acuerdo con POSIX:

Definición de un nombre de ruta:

Una cadena que se usa para identificar un archivo. Tiene caracteres iniciales <barra inclinada> opcionales , seguidos de cero o más nombres de archivo separados por caracteres <barra inclinada> . Un nombre de ruta puede contener opcionalmente uno o más caracteres <barra inclinada> finales . Se considera que varios caracteres <slash> sucesivos son iguales a uno <slash> , excepto en el caso de exactamente dos caracteres <slash> iniciales.


@ Es interesante, que puedo cd //y /con su nombre mostrar de manera diferente en el indicador de bash, y usando se pwdmostrará una ruta diferente, pero su contenido es idéntico. ¿Por qué?
Zen


1
Porque bashrastrea el directorio actual de una manera muy ingenua, como una cadena. Simplemente se agrega y elimina de la ruta heurísticamente, no se vincula al sistema de archivos real. Una consecuencia es que puede crear un CD en un enlace simbólico y volver de la misma manera (si bash no decidió que era demasiado y lo reinicializó). El otro es lo que usted describe. No debe confiar en el seguimiento del shell del directorio actual, no es confiable.
orion


6

Para estar seguro, incluya la barra oblicua. Esto puede conducir a múltiples barras al concatenar los caminos, pero al menos evita problemas.

Algunos ejemplos: rsynctrata las rutas de manera diferente si se incluye la barra diagonal final (sincroniza ese directorio en lugar de crear otro subdirectorio). Los enlaces simbólicos a directorios a veces se comportan de manera inesperada cuando no tienen la barra diagonal final; al menos, la finalización del shell se confunde. Nunca se sabe si el comando / secuencia de comandos que invocas se basa en la comprobación de la barra para un comportamiento especial. Incluso podría salvarte de sobrescribir algo. Por ejemplo, si tiene un archivo llamado foo, pero cree erróneamente que es un directorio y desea mover algo en él, mv bar foosobrescribirá el archivo (pérdida de datos, posible catástrofe) pero mv bar foo/simplemente se quejará y no hará nada.

Para concluir, en la mayoría de los casos no importa, pero debe usar la barra oblicua para protegerse y también para que sea más obvio para el lector humano lo que pretendía hacer en un guión. Un observador casual se asegurará de inmediato de que una variable se refiera a un directorio si termina con una barra oblicua, y la usará correctamente si necesita ser modificada.


2

No, no deberías. Agrega una barra extra innecesaria ( /).

ejemplo

digamos que desea exportar el bindirectorio de java a su PATHvariable,

export PATH=$PATH:/opt/jre1.7.0_45/bin/

ahora compruébalo,

user@host:~$ which java
/opt/jre1.7.0_45/bin//java

observe la barra oblicua adicional ( /) antes de Java, pero afortunadamente solo funciona en tal caso.


Vi en este enlace que hay una respuesta de 31 votos en la que el autor piensa que deberíamos agregar una barra oblicua. Estoy confundido. stackoverflow.com/questions/980255/…
Zen

@ Zen, sí, lo revisé, fue en el primer comentario de tu pregunta. Gracias.
Arnab

66
Mejor dos cortes que ninguno. Esta es fea pero segura ... la otra opción es mucho peor y puede ser peligrosa.
orion
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.