Come test non invasivo per l'accesso in scrittura a un file?

In uno script di shell, come posso testare in modo semplice e non invasivo l' accesso in scrittura a un file senza tentare effettivamente di modificare il file?

Potrei analizzare l'output di stat, ma sembra davvero complesso, e forse fragile, anche se non sono sicuro di quanto output stat differisca tra implementazioni e tempo.

Potrei aggiungere alla fine del file e vedere se ciò ha esito positivo, ma è potenzialmente pericoloso, per due motivi a cui posso pensare:

1. Ora devo rimuovere l'aggiunta e, nel caso in cui qualche altro processo scriva nel file, questo diventa immediatamente non banale poiché la mia linea non è più l'ultima.
2. Qualsiasi processo di lettura del file può avere requisiti arbitrari sul contenuto di quel file e potrei aver rotto l'applicazione.

Basta usare la - wbandiera testdell'utilità:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Nota che se hai intenzione di scrivere sul file in un secondo momento, è ancora possibile che non sarai in grado di scrivere su di esso. Il file potrebbe essere stato spostato, le autorizzazioni potrebbero essere state modificate, ecc. Può anche accadere che -wrilevi le autorizzazioni di scrittura ma alcuni altri fattori intervengono per rendere il file non scrivibile .

Un altro approccio:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Ciò tenterà di aprire il file per l'aggiunta e, se ciò ha esito positivo, non esegue alcun comando (ovvero, esegue un comando null ) con l'output nel file. 

Attenzione che questo crea un file vuoto se non esistesse.

L' -woperatore del testcomando potrebbe semplicemente fare una stat e quindi provare a capire se sembra che tu debba avere accesso. La mia alternativa (sopra) è più affidabile testdell'approccio in alcune condizioni speciali, perché forza il controllo di accesso che deve essere eseguito dal kernel piuttosto che dalla shell. Per esempio,

• se il file si trova su un file system non Unix, specialmente se è montato in remoto da un file server non Unix, perché statpotrebbe restituire un valore di modalità fuorviante.
• se il file si trova su un file system montato di sola lettura.
• se il file ha un ACL e la modalità fa sembrare che dovresti avere accesso, ma l'ACL lo nega, o viceversa.
• se qualche framework di sicurezza (AppArmor, SELinux, ...) nega l'accesso al file.

G-man ha ragione: [ -w ]non dirà sempre la verità. Qui per far fronte a file inesistenti e messaggio di autorizzazione negata dalla shell:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Aggiornamento : sembra spaventoso, no? Beh, lo è. Hmm ... come esprimerlo ... NON USARLO, a meno che tu non sappia perfettamente di essere nelle condizioni in cui richiede di funzionare come previsto. Vedi il commento di Stephane.

Cosa concludere, allora? Anche se [ -w ]non dice la verità, è l'unico comando che è destinato a fare il lavoro. In caso contrario, biasimeremo, scriveremo segnalazioni di bug e funzionerà in futuro. Verificare meglio le condizioni in cui funziona e utilizzare [ -w ]; scrivere un codice speciale per casi speciali. Le soluzioni alternative hanno le loro condizioni.

[ -w /path/to/file ]

è il migliore a priori .