¿Hay alguna desventaja de configurar `noclobber`?

Dado que zshpuede bloquear todos los archivos con el comando:

>*

Estoy pensando que establecer la opción noclobbersería una buena idea.

Siempre puedo usar >| filesi quiero usar el comportamiento de clobber predeterminado en bash y zsh. (zsh también permite la sintaxis alternativa >!file).

Supongo que no noclobberestá configurado por defecto debido a la compatibilidad POSIX, pero solo para estar seguro:

¿Hay alguna desventaja en la configuración noclobber?

¿Hay alguna forma de establecer noclobbersolo para el shell interactivo?

bash shell zsh

— Tom Hale
fuente

Estoy sorprendido zsh como mínimo, no avisa de ello, dado que se advierte sobre algo así rm *...

— ilkkachu

Respuestas:

La razón por la noclobberque no se establece por defecto es la tradición. Como cuestión de diseño de interfaz de usuario, es una buena idea hacer que "crear este nuevo archivo" sea una acción fácil y poner un obstáculo adicional a la acción más peligrosa "ya sea crear un nuevo archivo o sobrescribir un archivo existente". Por noclobberlo tanto, es una buena idea ( >crear un nuevo archivo, >|potencialmente sobrescribir un archivo existente) y probablemente habría sido el valor predeterminado si el shell se hubiera diseñado unas décadas más tarde.

Recomiendo usar lo siguiente en su archivo de inicio de shell interactivo ( .bashrco .zshrc):

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

En cada caso (redirección, copia, movimiento), el objetivo es agregar un obstáculo adicional cuando la operación puede tener el efecto secundario de borrar algunos datos existentes, a pesar de que borrar los datos existentes no es el objetivo principal de la operación. No pongo rm -ien esta lista porque el objetivo principal es borrar datos rm.

Tenga en cuenta que noclobbery -ison redes de seguridad . Si se disparan, has hecho algo mal . ¡Así que no los use como excusa para no verificar lo que está sobrescribiendo! El punto es que deberías haber verificado que el archivo de salida no existe. Si le dicen file exists: fooo overwrite 'foo'?, significa que cometió un error y debe sentirse mal y tener más cuidado. En particular, no tenga el hábito de decir ysi se le pide que sobrescriba (podría decirse que los alias deberían serlo alias cp='yes n | cp -i' mv='yes n | mv -i', pero presionar Ctrl+ Chace que la salida se vea mejor): si quiso sobrescribir, cancele el comando, mueva o elimine la salida archivo y ejecute el comando nuevamente.

También es importante no acostumbrarse a activar esos dispositivos de seguridad porque si lo hace, algún día estará en una máquina que no tiene su configuración, y perderá datos porque las protecciones con las que contaba no son t allí.

noclobbersolo se configurará para shells interactivos, ya que .bashrco .zshrcsolo se leerá con shells interactivos. Por supuesto, no debe cambiar las opciones de shell de una manera que afecte los scripts, ya que podría romper esos scripts.

— Gilles 'SO- deja de ser malvado'
fuente

rmtiene una opción -Ique uso y recomiendo: "preguntar una vez antes de eliminar más de tres archivos, o al eliminar de forma recursiva; menos intrusivo que -i, a la vez que brinda protección contra la mayoría de los errores"

— Reid

Recomiendo no volver a crear alias cp y mv de esa manera. Sin embargo, usarlos -icomo argumento predeterminado es una excelente idea, pero debe aplicarse con diferentes nombres de alias , no con los originales (por ejemplo, siempre pongo alias copy="cp -i"y alias move="mv -i"en mi .bashrc). ¿Por qué? Debido al modo de falla. ¿Qué sucede cuando usa una máquina o un usuario diferente que no tiene los alias cp / mv? Archivos potencialmente sobrescritos involuntariamente (¡posiblemente no detectados!). Modo de falla correspondiente con alias de copiar / mover: shell se queja de que no reconoce el comando.

— hlovdal 01 de

También hay un modo de falla adicional para el alias cp / mv: cuando se escribe un script de shell, alguien que está acostumbrado a cp = "cp -i" alias podría escribir un comando cp incorrectamente esperando que se comporte como en un modo interactivo porque no hay Diferencia de nombre. Por el contrario, cada vez que escribo "copy somefile / some / where" sé que uso un alias y no el comando cp directamente. E incluso si pusiera una copia en un archivo de shell, fallaría de la misma manera que para el shell con alias perdido.

— hlovdal 01 de

Entonces, TL; DR, el consejo predeterminado para usar el -iargumento para cp y mv es excelente, pero el consejo de reutilizar los nombres de cp y mv es terriblemente malo. Es tan malo que tengo que dar un voto negativo a la respuesta. Cambie para usar diferentes nombres de alias y le daré un voto positivo.

— hlovdal 01 de

@TomHale Se podría usar alias RM='command rm', lo que le indicaría a zsh que use el comando externo en rmlugar del alias. De esa manera no tienes que confiar en --interactive=neverreemplazar a un anterior -i.

— Adaephon

Establecer la noclobberopción de shell en ~/.bashrc(para bash) o ~/.zshrc(o más precisamente $ZDOTDIR/.zshrc, para zsh) la activará en sesiones de shell interactivas.

Los shells no interactivos (scripts) no leen estos archivos.

Las opciones de shell normalmente no se heredan de los shells principales.

Esto significa que debería poder establecer la opción en esos archivos sin modificar el comportamiento en los scripts existentes, a menos que los scripts exploten esos archivos.

El único inconveniente de hacer esto que puedo ver es que olvidará repetidamente que ha configurado la opción, al menos al principio. Más tarde, al igual que con todo este tipo de cosas, usted comenzará a uso habitual >|, incluso en los casos en los que en realidad podría no querer darle una paliza el archivo (al igual que las personas con alias para rm, cpy mvcon la -iopción siempre se establece, con el tiempo comenzará a siempre uso -fen la línea de comando).

— Kusalananda
fuente

Con bash, las opciones se heredan si $SHELLOPTS( $BASHOPTSpara las que shoptestán) en el entorno (no es algo que generalmente desearía hacer por este tipo de razón).

— Stéphane Chazelas

La desventaja es que, si se acostumbran a tener noclobberactiva, que un día se utiliza un sistema en el que se no se activa y se le alegremente ejecutar un comando potencialmente peligrosa, esperando lo noclobberque te salve ... y no lo hará. Y luego tendrá que esperar que haya una copia de seguridad lo suficientemente reciente como para recuperar los datos que destruyó porque asumió que primero se le pediría una confirmación.

— Dave Sherohman
fuente

Claro, un día usarás un sistema donde no está activo. Cuando utilice un sistema desconocido, debe tener especial cuidado y asegurarse de que las copias de seguridad estén actualizadas antes de hacer algo potencialmente destructivo como redirigir la salida a un archivo.

— Gilles 'SO- deja de ser malvado'