¿Cómo puedo verificar si un archivo se puede crear o truncar / sobrescribir en bash?

El usuario llama a mi script con una ruta de archivo que se creará o se sobrescribirá en algún momento del script, como foo.sh file.txto foo.sh dir/file.txt.

El comportamiento de crear o sobrescribir es muy similar a los requisitos para colocar el archivo en el lado derecho del >operador de redireccionamiento de salida, o pasarlo como argumento a tee(de hecho, pasarlo como argumento teees exactamente lo que estoy haciendo) )

Antes de entrar en las entrañas de la secuencia de comandos, quiero hacer una verificación razonable si el archivo se puede crear / sobrescribir, pero no crearlo realmente. Esta verificación no tiene que ser perfecta, y sí, me doy cuenta de que la situación puede cambiar entre la verificación y el punto en el que el archivo está realmente escrito, pero aquí estoy de acuerdo con una solución de tipo de mejor esfuerzo para poder rescatarme temprano en el caso de que la ruta del archivo no sea válida.

Ejemplos de razones por las que el archivo no se pudo crear:

• el archivo contiene un componente de directorio, dir/file.txtpero el directorio dirno existe
• el usuario no tiene permisos de escritura en el directorio especificado (o el CWD si no se especificó ningún directorio

Sí, me doy cuenta de que verificar los permisos "por adelantado" no es The UNIX Way ™ , sino que debería probar la operación y pedir perdón más tarde. Sin embargo, en mi script en particular, esto conduce a una mala experiencia de usuario y no puedo cambiar el componente responsable.

La prueba obvia sería:

if touch /path/to/file; then
    : it can be created
fi

Pero en realidad crea el archivo si aún no está allí. Podríamos limpiar después de nosotros mismos:

if touch /path/to/file; then
    rm /path/to/file
fi

Pero esto eliminaría un archivo que ya existía, que probablemente no desee.

Sin embargo, tenemos una forma de evitar esto:

if mkdir /path/to/file; then
    rmdir /path/to/file
fi

No puede tener un directorio con el mismo nombre que otro objeto en ese directorio. No puedo pensar en una situación en la que pueda crear un directorio pero no crear un archivo. Después de esta prueba, su script tendrá libertad para crear un convencional /path/to/filey hacer lo que le plazca.

De lo que estoy reuniendo, quieres verificar eso cuando uses

tee -- "$OUT_FILE"

(tenga en cuenta que --o no funcionaría para los nombres de archivo que comienzan con -), teepodría abrir el archivo para escribir.

Eso es eso:

• la longitud de la ruta del archivo no excede el límite PATH_MAX
• el archivo existe (después de la resolución del enlace simbólico) y no es de tipo directorio y tiene permiso de escritura.
• si el archivo no existe, el nombre de directorio del archivo existe (después de la resolución del enlace simbólico) como un directorio y tiene permiso de escritura y búsqueda y la longitud del nombre de archivo no excede el límite NAME_MAX del sistema de archivos en el que reside el directorio.
• o el archivo es un enlace simbólico que apunta a un archivo que no existe y no es un bucle de enlace simbólico pero cumple con los criterios anteriores

Ignoraremos por ahora los sistemas de archivos como vfat, ntfs o hfsplus que tienen limitaciones sobre los valores de byte que pueden contener los nombres de archivos, la cuota de disco, el límite de proceso, selinux, apparmor u otro mecanismo de seguridad en el camino, sistema de archivos completo, no queda ningún inodo, dispositivo archivos que no se pueden abrir de esa manera por una razón u otra, archivos que son ejecutables actualmente asignados en algún espacio de direcciones de proceso, todo lo cual también podría afectar la capacidad de abrir o crear el archivo.

Con zsh:

zmodload zsh/system
tee_would_likely_succeed() {
  local file=$1 ERRNO=0 LC_ALL=C
  if [ -d "$file" ]; then
    return 1 # directory
  elif [ -w "$file" ]; then
    return 0 # writable non-directory
  elif [ -e "$file" ]; then
    return 1 # exists, non-writable
  elif [ "$errnos[ERRNO]" != ENOENT ]; then
    return 1 # only ENOENT error can be recovered
  else
    local dir=$file:P:h base=$file:t
    [ -d "$dir" ] &&    # directory
      [ -w "$dir" ] &&  # writable
      [ -x "$dir" ] &&  # and searchable
      (($#base <= $(getconf -- NAME_MAX "$dir")))
    return
  fi
}

En basho cualquier shell similar a Bourne, simplemente reemplace el

zmodload zsh/system
tee_would_likely_succeed() {
  <zsh-code>
}

con:

tee_would_likely_succeed() {
  zsh -s -- "$@" << 'EOF'
  zmodload zsh/system
  <zsh-code>
EOF
}

Las zshcaracterísticas específicas aquí son $ERRNO(que expone el código de error de la última llamada al sistema) y una $errnos[]matriz asociativa para traducir a los nombres de macro C estándar correspondientes. Y el $var:h(de csh) y $var:P(necesita zsh 5.3 o superior).

bash aún no tiene características equivalentes.

$file:hpuede ser reemplazado con dir=$(dirname -- "$file"; echo .); dir=${dir%??}, o con GNU dirname: IFS= read -rd '' dir < <(dirname -z -- "$file").

Para $errnos[ERRNO] == ENOENT, un enfoque podría ser ejecutar ls -Lden el archivo y verificar si el mensaje de error corresponde al error ENOENT. Sin embargo, hacer eso de manera confiable y portátil es complicado.

Un enfoque podría ser:

msg_for_ENOENT=$(LC_ALL=C ls -d -- '/no such file' 2>&1)
msg_for_ENOENT=${msg_for_ENOENT##*:}

(suponiendo que el mensaje de error termina con la syserror()traducción de ENOENTy que esa traducción no incluye a :) y luego, en lugar de [ -e "$file" ], hacer:

err=$(ls -Ld -- "$file" 2>&1)

Y compruebe si hay un error ENOENT con

case $err in
  (*:"$msg_for_ENOENT") ...
esac

La $file:Pparte es la más difícil de lograr bash, especialmente en FreeBSD.

FreeBSD tiene un realpathcomando y un readlinkcomando que acepta una -fopción, pero no se pueden usar en los casos en que el archivo es un enlace simbólico que no se resuelve. Eso es lo mismo con perl's Cwd::realpath().

python'S os.path.realpath()no parece funcionar de manera similar a zsh $file:P, por lo que suponiendo que al menos una versión de pythonestá instalado y que hay un pythoncomando que se refiere a uno de ellos, se puede hacer (que no es un hecho en FreeBSD es):

dir=$(python -c '
import os, sys
print(os.path.realpath(sys.argv[1]) + ".")' "$dir") || return
dir=${dir%.}

Pero entonces, también podrías hacer todo el asunto python.

O podría decidir no manejar todos esos casos de esquina.

Una opción que quizás desee considerar es crear el archivo desde el principio, pero solo completarlo más adelante en su secuencia de comandos. Puede usar el execcomando para abrir el archivo en un descriptor de archivo (como 3, 4, etc.) y luego usar una redirección a un descriptor de archivo ( >&3, etc.) para escribir contenidos en ese archivo.

Algo como:

#!/bin/bash

# Open the file for read/write, so it doesn't get
# truncated just yet (to preserve the contents in
# case the initial checks fail.)
exec 3<>dir/file.txt || {
    echo "Error creating dir/file.txt" >&2
    exit 1
}

# Long checks here...
check_ok || {
    echo "Failed checks" >&2
    # cleanup file before bailing out
    rm -f dir/file.txt
    exit 1
}

# We're ready to write, first truncate the file.
# Use "truncate(1)" from coreutils, and pass it
# /dev/fd/3 so the file doesn't need to be reopened.
truncate -s 0 /dev/fd/3

# Now populate the file, use a redirection to write
# to the previously opened file descriptor.
populate_contents >&3

También puede usar a trappara limpiar el archivo por error, es una práctica común.

De esta manera, obtienes una verificación real de los permisos para poder crear el archivo, al mismo tiempo que puedes realizarlo lo suficientemente temprano como para que si eso falla, no hayas pasado tiempo esperando las largas verificaciones.

ACTUALIZADO: para evitar tropezar con el archivo en caso de que las comprobaciones fallen, utilice la fd<>fileredirección de bash que no trunca el archivo de inmediato. (No nos importa leer el archivo, esto es solo una solución alternativa, por lo que no lo truncamos. Anexar con >>probablemente probablemente también funcione, pero tiendo a encontrar este un poco más elegante, manteniendo el indicador O_APPEND fuera de la foto.)

Cuando estemos listos para reemplazar el contenido, primero debemos truncar el archivo (de lo contrario, si estamos escribiendo menos bytes de los que había antes en el archivo, los bytes finales permanecerían allí). Podemos usar el truncado (1) comando de coreutils para ese propósito, y podemos pasarle el descriptor de archivo abierto que tenemos (usando el /dev/fd/3pseudo-archivo) para que no necesite volver a abrir el archivo. (Nuevamente, técnicamente algo más simple como : >dir/file.txtprobablemente funcionaría, pero no tener que volver a abrir el archivo es una solución más elegante).

Creo que la solución de DopeGhoti es mejor, pero esto también debería funcionar:

file=$1
if [[ "${file:0:1}" == '/' ]]; then
    dir=${file%/*}
elif [[ "$file" =~ .*/.* ]]; then
    dir="$(PWD)/${file%/*}"
else
    dir=$(PWD)
fi

if [[ -w "$dir" ]]; then
    echo "writable"
    #do stuff with writable file
else
    echo "not writable"
    #do stuff without writable file
fi

La primera construcción if comprueba si el argumento es una ruta completa (comienza con /) y establece la dirvariable en la ruta del directorio hasta la última /. De lo contrario, si el argumento no comienza con a /pero contiene un /(especificando un subdirectorio) se establecerá diren el directorio de trabajo actual + la ruta del subdirectorio. De lo contrario, asume el directorio de trabajo actual. Luego verifica si ese directorio es grabable.

¿Qué pasa con el uso del testcomando normal como se describe a continuación?

FILE=$1

DIR=$(dirname $FILE) # $DIR now contains '.' for file names only, 'foo' for 'foo/bar'

if [ -d $DIR ] ; then
  echo "base directory $DIR for file exists"
  if [ -e $FILE ] ; then
    if [ -w $FILE ] ; then
      echo "file exists, is writeable"
    else
      echo "file exists, NOT writeable"
    fi
  elif [ -w $DIR ] ; then
    echo "directory is writeable"
  else
    echo "directory is NOT writeable"
  fi
else
  echo "can NOT create file in non-existent directory $DIR "
fi

Usted mencionó que la experiencia del usuario estaba impulsando su pregunta. Contestaré desde un ángulo UX, ya que tienes buenas respuestas en el aspecto técnico.

En lugar de realizar la verificación por adelantado, ¿qué hay de escribir los resultados en un archivo temporal y luego, al final, colocar los resultados en el archivo deseado por el usuario? Me gusta:

userfile=${1:?Where would you like the file written?}
tmpfile=$(mktemp)

# ... all the complicated stuff, writing into "${tmpfile}"

# fill user's file, keeping existing permissions or creating anew
# while respecting umask
cat "${tmpfile}" > "${userfile}"
if [ 0 -eq $? ]; then
    rm "${tmpfile}"
else
    echo "Couldn't write results into ${userfile}." >&2
    echo "Results available in ${tmpfile}." >&2
    exit 1
fi

Lo bueno de este enfoque: produce la operación deseada en el escenario normal de ruta feliz, evita el problema de atomicidad de prueba y configuración, conserva los permisos del archivo de destino mientras se crea si es necesario, y es muy simple de implementar.

Nota: si lo hubiéramos usado mv, estaríamos manteniendo los permisos del archivo temporal; creo que no queremos eso: queremos mantener los permisos tal como están establecidos en el archivo de destino.

Ahora, lo malo: requiere el doble de espacio ( cat .. >construcción), obliga al usuario a hacer un trabajo manual si el archivo de destino no se puede escribir en el momento en que lo necesitaba, y deja el archivo temporal por ahí (lo que podría tener seguridad o problemas de mantenimiento).

TL; DR:

: >> "${userfile}"

A diferencia de <> "${userfile}"o touch "${userfile}", esto no hará modificaciones espurias a las marcas de tiempo del archivo y también funcionará con archivos de solo escritura.

Desde el OP:

Quiero hacer una comprobación razonable si el archivo se puede crear / sobrescribir, pero no crearlo realmente.

Y de tu comentario a mi respuesta desde una perspectiva UX :

La gran mayoría de las veces esto falla porque la ruta proporcionada no es válida. No puedo evitar razonablemente que algún usuario deshonesto modifique simultáneamente el FS para interrumpir el trabajo en medio de la operación, pero ciertamente puedo verificar la causa de falla n. ° 1 de una ruta no válida o no editable.

La única prueba confiable es open(2)el archivo, porque solo eso resuelve todas las preguntas sobre la capacidad de escritura: ruta, propiedad, sistema de archivos, red, contexto de seguridad, etc. Cualquier otra prueba abordará una parte de la capacidad de escritura, pero no otras. Si desea un subconjunto de pruebas, finalmente tendrá que elegir lo que es importante para usted.

Pero aquí hay otro pensamiento. Por lo que entiendo:

1. el proceso de creación de contenido es de larga duración y
2. El archivo de destino debe dejarse en un estado coherente.

Desea hacer esta verificación previa debido al n. ° 1, y no quiere jugar con un archivo existente debido al n. ° 2. Entonces, ¿por qué no le pide al shell que abra el archivo para agregarlo, pero en realidad no agrega nada?

$ tree -ps
.
├── [dr-x------        4096]  dir_r
├── [drwx------        4096]  dir_w
├── [-r--------           0]  file_r
└── [-rw-------           0]  file_w

$ for p in file_r dir_r/foo file_w dir_w/foo; do : >> $p; done
-bash: file_r: Permission denied
-bash: dir_r/foo: Permission denied

$ tree -ps
.
├── [dr-x------        4096]  dir_r
├── [drwx------        4096]  dir_w
│   └── [-rw-rw-r--           0]  foo
├── [-r--------           0]  file_r
└── [-rw-------           0]  file_w

Debajo del capó, esto resuelve la pregunta de escritura exactamente como se quería:

open("dir_w/foo", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

pero sin modificar los contenidos o metadatos del archivo. Ahora, sí, este enfoque:

• no te dice si el archivo es solo agregar, lo que podría ser un problema cuando actualizas al final de tu creación de contenido. Puede detectar esto, hasta cierto punto, lsattry reaccionar en consecuencia.
• crea un archivo que no existía anteriormente, si ese es el caso: mitigue esto con un selectivo rm.

Si bien afirmo (en mi otra respuesta) que el enfoque más fácil de usar es crear un archivo temporal que el usuario tenga que mover, creo que este es el enfoque menos hostil para el usuario para examinar completamente su entrada.