Comment puis-je vérifier si un fichier peut être créé ou tronqué / écrasé dans bash?

L'utilisateur appelle mon script avec un chemin de fichier qui sera soit créé soit écrasé à un moment donné du script, comme foo.sh file.txtou foo.sh dir/file.txt.

Le comportement de création ou d'écrasement ressemble beaucoup aux exigences pour placer le fichier du côté droit de l' >opérateur de redirection de sortie, ou le passer comme argument à tee(en fait, le passer comme argument à teeest exactement ce que je fais) ).

Avant d'entrer dans les tripes du script, je veux vérifier raisonnablement si le fichier peut être créé / écrasé, mais pas réellement le créer. Cette vérification ne doit pas être parfaite, et oui je me rends compte que la situation peut changer entre la vérification et le point où le fichier est réellement écrit - mais ici, je suis OK avec une solution de type meilleur effort afin que je puisse renflouer tôt dans le cas où le chemin du fichier n'est pas valide.

Exemples de raisons pour lesquelles le fichier n'a pas pu être créé:

• le fichier contient un composant de répertoire, comme dir/file.txtmais le répertoire dirn'existe pas
• l'utilisateur n'a pas d'autorisations d'écriture dans le répertoire spécifié (ou le CWD si aucun répertoire n'a été spécifié

Oui, je me rends compte que la vérification des autorisations "à l'avance" n'est pas The UNIX Way ™ , je devrais plutôt essayer l'opération et demander pardon plus tard. Cependant, dans mon script particulier, cela conduit à une mauvaise expérience utilisateur et je ne peux pas changer le composant responsable.

Le test évident serait:

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

Mais il crée réellement le fichier s'il n'est pas déjà là. Nous pourrions nettoyer après nous:

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

Mais cela supprimerait un fichier qui existait déjà, ce que vous ne voulez probablement pas.

Nous avons cependant un moyen de contourner cela:

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

Vous ne pouvez pas avoir un répertoire portant le même nom qu'un autre objet dans ce répertoire. Je ne peux pas penser à une situation dans laquelle vous seriez en mesure de créer un répertoire mais pas de créer un fichier. Après ce test, votre script serait libre de créer un conventionnel /path/to/fileet de faire ce qui lui plaira.

D'après ce que je recueille, vous voulez vérifier que lors de l'utilisation

tee -- "$OUT_FILE"

(notez que le --ou cela ne fonctionnerait pas pour les noms de fichiers commençant par -), teeréussirait à ouvrir le fichier en écriture.

C'est ça:

• la longueur du chemin du fichier ne dépasse pas la limite PATH_MAX
• le fichier existe (après la résolution du lien symbolique) et n'est pas de type répertoire et vous y avez l'autorisation d'écriture.
• si le fichier n'existe pas, le nom du fichier existe (après la résolution du lien symbolique) en tant que répertoire et vous y avez l'autorisation d'écrire et de rechercher et la longueur du nom de fichier ne dépasse pas la limite NAME_MAX du système de fichiers dans lequel se trouve le répertoire.
• ou le fichier est un lien symbolique qui pointe vers un fichier qui n'existe pas et qui n'est pas une boucle de lien symbolique mais qui répond aux critères juste au-dessus

Nous ignorerons pour l'instant les systèmes de fichiers comme vfat, ntfs ou hfsplus qui ont des limitations sur les valeurs d'octets que les noms de fichiers peuvent contenir, quota de disque, limite de processus, selinux, apparmor ou autre mécanisme de sécurité, système de fichiers complet, pas d'inode restant, périphérique les fichiers qui ne peuvent pas être ouverts de cette façon pour une raison ou une autre, les fichiers exécutables actuellement mappés dans un espace d'adressage de processus, tous pouvant également affecter la possibilité d'ouvrir ou de créer le fichier.

Avec 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
}

Dans bashou n'importe quel shell de type Bourne, remplacez simplement le

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

avec:

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

Les zshfonctionnalités spécifiques ici sont $ERRNO(qui exposent le code d'erreur du dernier appel système) et un $errnos[]tableau associatif à traduire dans les noms de macro C standard correspondants. Et le$var:h (à partir de csh) et $var:P(nécessite zsh 5.3 ou supérieur).

bash n'a pas encore de fonctionnalités équivalentes.

$file:hpeut être remplacé par dir=$(dirname -- "$file"; echo .); dir=${dir%??}ou par GNU dirname:IFS= read -rd '' dir < <(dirname -z -- "$file") .

Car $errnos[ERRNO] == ENOENT, une approche pourrait consister à exécuterls -Ld le fichier et à vérifier si le message d'erreur correspond à l'erreur ENOENT. Il est cependant difficile de le faire de manière fiable et portable.

Une approche pourrait être:

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

(en supposant que le message d'erreur se termine par la syserror()traduction de ENOENTet que cette traduction n'inclut pas a :), puis, au lieu de [ -e "$file" ], procédez comme suit :

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

Et recherchez une erreur ENOENT avec

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

La $file:Ppartie est la plus délicate à réaliser en bashparticulier sur FreeBSD.

FreeBSD a une realpathcommande et une readlinkcommande qui accepte une -foption, mais elles ne peuvent pas être utilisées dans les cas où le fichier est un lien symbolique qui ne se résout pas. C'est la même chose avec perl« s Cwd::realpath().

python« s os.path.realpath()ne semble fonctionner de façon similaire à zsh $file:P, donc en supposant qu'au moins une version pythonest installée et qu'il ya une pythoncommande qui fait référence à l' un d'entre eux ( ce qui est une donnée sur FreeBSD), vous pouvez faire:

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

Mais alors, vous pourriez aussi bien faire tout cela python.

Ou vous pourriez décider de ne pas gérer tous ces cas d'angle.

Une option que vous voudrez peut-être envisager est de créer le fichier au début, mais de le remplir plus tard dans votre script. Vous pouvez utiliser la execcommande pour ouvrir le fichier dans un descripteur de fichier (tel que 3, 4, etc.), puis utiliser ultérieurement une redirection vers un descripteur de fichier ( >&3, etc.) pour écrire du contenu dans ce fichier.

Quelque chose comme:

#!/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

Vous pouvez également utiliser un trappour nettoyer le fichier en cas d'erreur, c'est une pratique courante.

De cette façon, vous obtenez une véritable vérification des autorisations que vous pourrez créer le fichier, tout en étant en mesure de l'exécuter suffisamment tôt pour que si cela échoue, vous n'avez pas passé de temps à attendre les longues vérifications.

MISE À JOUR: Afin d'éviter de surcharger le fichier en cas d'échec des vérifications, utilisez la fd<>fileredirection de bash qui ne tronque pas immédiatement le fichier. (Nous ne nous soucions pas de la lecture du fichier, il s'agit simplement d'une solution de contournement, nous ne le tronquons donc pas.>> le tronquons fonctionnerait probablement aussi, mais j'ai tendance à trouver celui-ci un peu plus élégant, en gardant le drapeau O_APPEND sur de l'image.)

Lorsque nous sommes prêts à remplacer le contenu, nous devons d'abord tronquer le fichier (sinon, si nous écrivons moins d'octets qu'il n'y en avait auparavant, les octets de fin y resteront.) Nous pouvons utiliser la troncature (1) commande de coreutils à cet effet, et nous pouvons lui passer le descripteur de fichier ouvert que nous avons (en utilisant le /dev/fd/3pseudo-fichier) de sorte qu'il n'a pas besoin de rouvrir le fichier. (Encore une fois, quelque chose de plus simple sur le plan technique : >dir/file.txtfonctionnerait probablement, mais ne pas avoir à rouvrir le fichier est une solution plus élégante.)

Je pense que la solution de DopeGhoti est meilleure mais cela devrait également fonctionner:

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 première construction if vérifie si l'argument est un chemin complet (commence par /) et définit la dirvariable sur le chemin du répertoire jusqu'au dernier /. Sinon, si l'argument ne commence pas par un /mais contient un /(en spécifiant un sous-répertoire), il sera défini dirsur le répertoire de travail actuel + le chemin du sous-répertoire. Sinon, il suppose le répertoire de travail actuel. Il vérifie ensuite si ce répertoire est accessible en écriture.

Qu'en est-il de l'utilisation de la testcommande normale comme indiqué ci-dessous?

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

Vous avez mentionné que l'expérience utilisateur était à l'origine de votre question. Je répondrai sous un angle UX, car vous avez de bonnes réponses sur le plan technique.

Plutôt que d'effectuer la vérification à l'avance, que diriez-vous d'écrire les résultats dans un fichier temporaire puis à la fin, de placer les résultats dans le fichier souhaité par l'utilisateur? Comme:

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

Le bon avec cette approche: il produit l'opération souhaitée dans le scénario normal de chemin heureux, contourne le problème d'atomicité de test et de définition, préserve les autorisations du fichier cible lors de la création si nécessaire et est très simple à mettre en œuvre.

Remarque: si nous avions utilisé mv, nous conserverions les autorisations du fichier temporaire - nous ne voulons pas cela, je pense: nous voulons conserver les autorisations telles qu'elles sont définies dans le fichier cible.

Maintenant, le mauvais: il nécessite deux fois plus d'espace ( cat .. >construction), oblige l'utilisateur à effectuer un travail manuel si le fichier cible n'était pas accessible en écriture au moment où il devait l'être, et laisse le fichier temporaire en place (ce qui pourrait avoir la sécurité) ou problèmes de maintenance).

TL; DR:

: >> "${userfile}"

Contrairement à <> "${userfile}"ou touch "${userfile}", cela n'apportera aucune modification parasite aux horodatages du fichier et fonctionnera également avec les fichiers en écriture seule.

Du PO:

Je veux faire une vérification raisonnable si le fichier peut être créé / écrasé, mais pas vraiment le créer.

Et de votre commentaire à ma réponse du point de vue UX :

La grande majorité du temps, cela échoue parce que le chemin d'accès fourni n'est pas valide. Je ne peux pas raisonnablement empêcher un utilisateur voyou de modifier simultanément le FS pour interrompre le travail au milieu de l'opération, mais je peux certainement vérifier la cause d'échec # 1 d'un chemin non valide ou non accessible en écriture.

Le seul test fiable concerne open(2)le fichier, car seul celui-ci résout toutes les questions sur l'écriture en écriture: chemin, propriété, système de fichiers, réseau, contexte de sécurité, etc. Tout autre test traitera une partie de l'écriture en écriture, mais pas d'autres. Si vous voulez un sous-ensemble de tests, vous devrez finalement choisir ce qui est important pour vous.

Mais voici une autre pensée. D'après ce que je comprends:

1. le processus de création de contenu est long et
2. le fichier cible doit être laissé dans un état cohérent.

Vous souhaitez effectuer cette pré-vérification en raison de # 1, et vous ne voulez pas jouer avec un fichier existant en raison de # 2. Alors pourquoi ne demandez-vous pas simplement au shell d'ouvrir le fichier pour l'ajout, mais n'ajoutez rien réellement?

$ 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

Sous le capot, cela résout la question de l'écriture exactement comme souhaité:

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

mais sans modifier le contenu ou les métadonnées du fichier. Maintenant, oui, cette approche:

• ne vous indique pas si le fichier est ajouté uniquement, ce qui peut poser problème lorsque vous procédez à sa mise à jour à la fin de la création de votre contenu. Vous pouvez le détecter, dans une certaine mesure, avec lsattret réagir en conséquence.
• crée un fichier qui n'existait pas auparavant, si tel est le cas: atténuez cela avec un sélectif rm.

Bien que je soutienne (dans mon autre réponse) que l' approche la plus conviviale consiste à créer un fichier temporaire que l'utilisateur doit déplacer, je pense que c'est l' approche la moins hostile à l' utilisateur pour contrôler pleinement son entrée.