Ci sono degli svantaggi nell'impostare `noclobber`?

Dato che zshpuò bloccare tutti i file dato il comando:

>*

Sto pensando che l'impostazione dell'opzione noclobbersarebbe una buona idea.

Posso sempre usare >| filese voglio usare il comportamento predefinito di clobber sia in bash che in zsh. (zsh consente anche la sintassi alternativa >!file).

Immagino che noclobbernon sia impostato di default a causa della compatibilità POSIX, ma per essere sicuro:

Ci sono degli svantaggi nell'impostazione noclobber?

Esiste un modo per impostare noclobbersolo per la shell interattiva?

bash shell zsh

— Tom Hale
fonte

Sono sorpreso che zsh non lo rm *

— metta

Risposte:

Il motivo noclobbernon è impostato di default è tradizione. Per quanto riguarda la progettazione dell'interfaccia utente, è una buona idea rendere "crea questo nuovo file" l'azione semplice e mettere un ulteriore ostacolo all'azione più pericolosa "o creare un nuovo file o sovrascrivere un file esistente". Quindi noclobberè una buona idea ( >creare un nuovo file, >|sovrascrivere potenzialmente un file esistente) e sarebbe probabilmente stato il default se la shell fosse stata progettata qualche decennio dopo.

Consiglio vivamente di utilizzare quanto segue nel file di avvio della shell interattivo ( .bashrco .zshrc):

set -o noclobber
alias cp='cp -i'
alias mv='mv -i'

In ogni caso (reindirizzamento, copia, spostamento), l'obiettivo è quello di aggiungere un ulteriore ostacolo quando l'operazione potrebbe avere l'effetto collaterale di cancellare alcuni dati esistenti, anche se la cancellazione di dati esistenti non è l'obiettivo principale dell'operazione. Non inserisco rm -iquesto elenco perché la cancellazione dei dati è l'obiettivo principale di rm.

Fare nota che noclobbere -isono reti di sicurezza . Se si innescano, hai fatto qualcosa di sbagliato . Quindi non usarli come scusa per non controllare ciò che stai sovrascrivendo! Il punto è che avresti dovuto verificare che il file di output non esistesse. Se ti viene detto file exists: fooo overwrite 'foo'?, significa che hai fatto un errore e dovresti sentirti male ed essere più attento. In particolare, non prendere l'abitudine di dire yse ti viene richiesto di sovrascrivere (probabilmente, gli alias dovrebbero essere alias cp='yes n | cp -i' mv='yes n | mv -i', ma premendo Ctrl+ Crende l'output migliore): se intendevi sovrascrivere, annullare il comando, spostare o rimuovere l'output file ed eseguire nuovamente il comando.

È anche importante non prendere l'abitudine di innescare quelle sicurezze perché se lo fai, un giorno sarai su una macchina che non ha la tua configurazione e perderai i dati perché le protezioni su cui contavi non sono lì.

noclobberverrà impostato solo per shell interattive, poiché .bashrco .zshrcviene letto solo da shell interattive. Ovviamente non dovresti cambiare le opzioni della shell in un modo che possa influenzare gli script, dal momento che potrebbe spezzarli.

— Gilles 'SO- smetti di essere cattivo'
fonte

rmha un'opzione -Iche uso e raccomando: "richiede una volta prima di rimuovere più di tre file o quando si rimuove in modo ricorsivo; meno invadente di -i, pur offrendo protezione contro la maggior parte degli errori"

— Reid

Consiglio vivamente di non ricollegare cp e mv in questo modo. Tuttavia, l'utilizzo -icome argomento predefinito per loro è un'ottima idea, ma dovrebbe essere applicato a nomi di alias diversi , non agli originali (ad esempio, ho sempre inserito alias copy="cp -i"e alias move="mv -i"nel mio .bashrc). Perché? A causa della modalità di errore. Cosa succede quando si utilizza una macchina o un utente diverso che non ha gli alias cp / mv? File potenzialmente sovrascritti involontariamente (possibilmente non rilevati!). Modalità di errore corrispondente con alias copia / sposta: la shell si lamenta di non riconoscere il comando.

— hlovdal

Esiste anche una modalità di errore aggiuntiva per l'alias cp / mv: quando si scrive uno script di shell qualcuno che viene usato per l'alias cp = "cp -i" potrebbe scrivere un comando cp in modo errato aspettandosi che si comporti come in una modalità interattiva perché non c'è differenza di nome. Al contrario, ogni volta che scrivo "copy somefile / some / where" so che uso direttamente un alias e non il comando cp. E anche se dovessi mettere una copia in un file shell, fallirebbe allo stesso modo della shell con alias mancante.

— hlovdal

Quindi TL; DR i consigli di default per usare l' -iargomento per cp e mv sono eccellenti, ma i consigli per riutilizzare i nomi cp e mv sono terribilmente cattivi. È così grave che devo dare un voto negativo alla risposta. Per favore cambia per usare nomi di alias diversi e darò un voto positivo.

— hlovdal

@TomHale Potresti usare alias RM='command rm', il che direbbe a zsh di usare il comando esterno rminvece dell'alias . In questo modo non devi fare affidamento sul --interactive=neversuperamento di un precedente -i.

— Adaefon,

L'impostazione noclobberdell'opzione shell in ~/.bashrc(for bash) o ~/.zshrc(o più precisamente $ZDOTDIR/.zshrc, for zsh) la renderà attiva nelle sessioni interattive della shell.

Le shell non interattive (script) non leggono questi file.

Le opzioni della shell non sono normalmente ereditate dalle shell principali.

Ciò significa che dovresti essere in grado di impostare l'opzione in quei file senza modificare il comportamento negli script esistenti, a meno che gli script non li generino esplicitamente.

L'unico aspetto negativo di ciò che posso vedere è che dimenticherai ripetutamente di aver impostato l'opzione, almeno all'inizio. Più tardi, come con tutto questo genere di cose, inizierai a utilizzare abitualmente >|, anche nei casi in cui potresti non voler ostruire il file (proprio come le persone con alias per rm, cpe mvcon l' -iopzione sempre impostata, alla fine inizieranno a utilizzare sempre -fsulla riga di comando).

— Kusalananda
fonte

Con bash, le opzioni sono ereditate se $SHELLOPTS( $BASHOPTSper shoptquelli) si trova nell'ambiente (non qualcosa che generalmente vorresti fare per questo tipo di ragione).

— Stéphane Chazelas,

Il rovescio della medaglia è che, se si diventa abituati ad avere noclobberattivo, è che un giorno utilizzare un sistema in cui esso non è attiva e si allegramente eseguire un comando potenzialmente pericoloso, aspettandosi il noclobberper salvare voi ... e non lo farà. E poi dovrai sperare che ci sia un backup abbastanza recente per recuperare i dati che hai distrutto perché pensavi che ti sarebbe stata chiesta prima la conferma.

— Dave Sherohman
fonte

Certo, un giorno utilizzerai un sistema in cui non è attivo. Quando si utilizza un sistema sconosciuto, è necessario prestare particolare attenzione e assicurarsi che i backup siano aggiornati prima di eseguire qualsiasi operazione potenzialmente distruttiva come il reindirizzamento dell'output su un file.

— Gilles 'SO- smetti di essere malvagio' il