
En un script de shell, ¿cómo puedo hacer fácil yde forma no invasiva¿Probar el acceso de escritura a un archivo sin intentar modificarlo?
Podría analizar el resultado de stat
, pero parece realmente complejo y quizás frágil, aunque no estoy seguro de en qué medida el resultado de las estadísticas difiere entre las implementaciones y el tiempo.
Podría agregarlo al final del archivo y ver si tiene éxito, pero eso es potencialmente peligroso, por dos razones que se me ocurren:
- Ahora tengo que eliminar la adición y, en caso de que algún otro proceso escriba en el archivo, esto inmediatamente deja de ser trivial ya que mi línea ya no es la última.
- Cualquier proceso que lea el archivo puede tener requisitos arbitrarios sobre el contenido de ese archivo, y es posible que haya roto esa aplicación.
Respuesta1
Sólo usa la - w
bandera deltest
utilidad:
[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"
Tenga en cuenta que si va a escribir en el archivo más tarde, aún es posible que no pueda escribir en él. Puede que el archivo se haya movido, que hayan cambiado los permisos, etc. También puede suceder que-w
detecta permisos de escritura pero interviene algún otro factor para que el archivo no se pueda escribir.
Respuesta2
Otro enfoque:
if >> /path/to/file
then
echo "writeable"
else
echo "write permission denied"
fi
Esto intentará abrir el archivo para agregarlo y, si tiene éxito, corrersin comando(es decir,ejecutar un comando nulo) con salida al archivo.
Tenga en cuenta que esto crea un archivo vacío si no existía.
El -w
operador del test
comando podría simplemente hacer un stat
y luego intentar averiguar si parece que usted debería tener acceso. Mi alternativa (arriba) es más confiable que el test
enfoque en algunas condiciones especiales, porque obliga a que la verificación de acceso la realice el kernel en lugar del shell. Por ejemplo,
- si el archivo está en un sistema de archivos que no es Unix, especialmente si se monta de forma remota desde un servidor de archivos que no es Unix, porque
stat
podría devolver un valor de modo que sea engañoso. - si el archivo está en un sistema de archivos montado como de solo lectura.
- si el archivo tiene una ACL y el modo hace que parezca que debería tener acceso, pero la ACL lo niega, o viceversa.
- si algún marco de seguridad (AppArmor, SELinux,…) niega el acceso al archivo.
Respuesta3
G-man tiene razón: [ -w ]
no lo harésiempredi la verdad. Aquí para hacer frente a archivos inexistentes yPermiso denegadomensaje del shell:
( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null &&
echo writable ||
echo not writable
Actualizar: Parece aterrador, ¿no? Bueno, lo es. Hmm... cómo decirlo... NO USE ESTO, a menos que sepa perfectamente que está en las condiciones que requiere para funcionar como se espera. Vea el comentario de Stéphane.
¿Qué concluir entonces? Incluso si [ -w ]
no dice la verdad, es el único comando que se cumple.destinadopara hacer el trabajo. Si no es así, lo culparemos, escribiremos informes de errores y funcionará en el futuro. Es mejor comprobar las condiciones en las que funciona y se utiliza [ -w ]
; escribir código especial para casos especiales. Las soluciones alternativas tienen sus propias condiciones.
[ -w /path/to/file ]
es la mejora priori.