¿Hay alguna desventaja de configurar `noclobber`?
Dado que zsh puede bloquear todos los archivos con el comando:
>*
Estoy pensando que establecer la opción noclobber sería una buena idea.
Siempre puedo usar >| file si quiero usar el comportamiento de clobber predeterminado en bash y zsh. (zsh también permite la sintaxis alternativa >!file).
Supongo que noclobber no está configurado por defecto debido a la compatibilidad POSIX, pero solo para estar seguro:
¿Hay algún inconveniente en configurar noclobber?
¿Hay alguna forma de establecer noclobber solo para el shell interactivo?
La razón por la que noclobber no está establecida de forma predeterminada 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 lo tanto, noclobber es una buena idea (> para crear un nuevo archivo, >| para sobrescribir potencialmente un archivo existente) y probablemente hubiera sido el predeterminado si el Shell se hubiera diseñado unas décadas más tarde.
Recomiendo usar lo siguiente en su archivo interactivo de inicio de Shell (.bashrc o .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 -i en esta lista porque borrar datos es el objetivo principal de rm.
Tenga en cuenta que noclobber y -i son 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 te dicen file exists: foo o overwrite 'foo'?, significa que cometiste un error y deberías sentirte mal y ser más cuidadoso. En particular, no tenga el hábito de decir y si se le pide que sobrescriba (posiblemente, los alias deberían ser alias cp='yes n | cp -i' mv='yes n | mv -i', pero presionando Ctrl+C hace que la salida se vea mejor): si desea sobrescribir, cancele el comando, mueva o elimine el archivo de salida y vuelva a ejecutar el comando.
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í.
noclobber solo se establecerá para shells interactivos, ya que .bashrc o .zshrc solo se lee mediante 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.
Establecer la opción noclobber Shell en ~/.bashrc (para bash) o ~/.zshrc (o más precisamente $ZDOTDIR/.zshrc, para zsh) lo activará en sesiones interactivas de Shell.
Los shells no interactivos (scripts) no leen estos archivos.
Las opciones de shell normalmente no se heredan de los shells principales.
Esto significa que debe 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, como con todo este tipo de cosas, comenzará a usar habitualmente >|, incluso en los casos en que es posible que no desee tropezar con el archivo (al igual que las personas con alias para rm, cp y mv con el -i opción siempre establecida, eventualmente comienza a usar siempre -f en la línea de comando).
La desventaja es que, si te acostumbras a tener noclobber activo, algún día usarás un sistema donde esté no activo y ejecutarás alegremente un comando potencialmente peligroso, esperando el noclobber para salvarte ... 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.