¿Por qué se diseñó `cp` para sobrescribir silenciosamente los archivos existentes? [cerrado]

Probé cpcon los siguientes comandos:

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

Luego copio first.htmla second.html:

$ cp first.html second.html

$ cat second.html
first

El archivo second.htmlse sobrescribe en silencio sin ningún error. Sin embargo, si lo hago en una GUI de escritorio arrastrando y soltando un archivo con el mismo nombre, se agregará el sufijo first1.htmlautomáticamente. Esto evita sobrescribir accidentalmente un archivo existente.

¿Por qué no cpsigue este patrón en lugar de sobrescribir archivos en silencio?

El comportamiento predeterminado de sobrescritura de cpse especifica en POSIX.

3. Si source_file es de tipo archivo regular, se seguirán los siguientes pasos:

   3.a. El comportamiento no se especifica si existe dest_file y se escribió en un paso anterior. De lo contrario, si existe dest_file, se seguirán los siguientes pasos:

   3.ai Si la opción -i está vigente, la utilidad cp escribirá un mensaje al error estándar y leerá una línea desde la entrada estándar. Si la respuesta no es afirmativa, cp no hará nada más con source_file y continuará con los archivos restantes.

   3.a.ii. Se obtendrá un descriptor de archivo para dest_file realizando acciones equivalentes a la función open () definida en el volumen de Interfaces del sistema de POSIX.1-2017 llamado utilizando dest_file como argumento de ruta, y el OR inclusivo a nivel de bit de O_WRONLY y O_TRUNC como el argumento de retraso.

   3.a.iii. Si el intento de obtener un descriptor de archivo falla y la opción -f está vigente, cp intentará eliminar el archivo realizando acciones equivalentes a la función unlink () definida en el volumen de Interfaces del sistema de POSIX.1-2017 llamado usando dest_file como el argumento del camino. Si este intento tiene éxito, cp continuará con el paso 3b.

Cuando se escribió la especificación POSIX, ya existía una gran cantidad de scripts, con una suposición incorporada para el comportamiento de sobrescritura predeterminado. Muchos de esos scripts fueron diseñados para ejecutarse sin la presencia directa del usuario, por ejemplo, como trabajos cron u otras tareas en segundo plano. Cambiar el comportamiento los habría roto. Revisarlos y modificarlos todos para agregar una opción para forzar la sobrescritura donde sea necesario probablemente se consideró una tarea enorme con beneficios mínimos.

Además, la línea de comandos de Unix siempre se diseñó para permitir que un usuario experimentado trabaje eficientemente, incluso a expensas de una curva de aprendizaje difícil para un principiante. Cuando el usuario ingresa un comando, la computadora debe esperar que el usuario realmente lo diga en serio, sin ninguna duda; Es responsabilidad del usuario tener cuidado con los comandos potencialmente destructivos.

Cuando se desarrolló el Unix original, los sistemas tenían tan poca memoria y almacenamiento masivo en comparación con las computadoras modernas que sobrescriben las advertencias y los avisos que probablemente se consideraron lujos innecesarios y derrochadores.

Cuando se estaba escribiendo el estándar POSIX, el precedente estaba firmemente establecido, y los escritores del estándar eran muy conscientes de las virtudes de no romper la compatibilidad con versiones anteriores .

Además, como otros han descrito, cualquier usuario puede agregar / habilitar esas funciones para sí mismo, utilizando alias de shell o incluso creando un cpcomando de reemplazo y modificando su $PATHpara encontrar el reemplazo antes del comando del sistema estándar, y obtener la red de seguridad de esa manera si deseado.

Pero si lo hace, descubrirá que está creando un peligro para usted. Si el cpcomando se comporta de una manera cuando se usa de manera interactiva y de otra manera cuando se lo llama desde un script, es posible que no recuerde que existe la diferencia. En otro sistema, puede terminar siendo descuidado porque está acostumbrado a las advertencias y avisos en su propio sistema.

Si el comportamiento en las secuencias de comandos aún coincidirá con el estándar POSIX, es probable que se acostumbre a las indicaciones en el uso interactivo, luego escriba una secuencia de comandos que haga algunas copias masivas y luego descubra que está sobrescribiendo algo sin darse cuenta.

Si aplica la solicitud en los scripts también, ¿qué hará el comando cuando se ejecute en un contexto que no tenga ningún usuario, por ejemplo, procesos en segundo plano o trabajos cron? ¿Se bloqueará, cancelará o sobrescribirá el script?

Colgar o abortar significa que una tarea que se suponía que debía hacerse automáticamente no se realizará. No sobrescribir a veces también puede causar un problema en sí mismo: por ejemplo, puede hacer que los datos antiguos sean procesados ​​dos veces por otro sistema en lugar de ser reemplazados por datos actualizados.

Una gran parte del poder de la línea de comando proviene del hecho de que una vez que sepa cómo hacer algo en la línea de comando, implícitamente también sabrá cómo hacer que suceda automáticamente mediante secuencias de comandos . Pero eso solo es cierto si los comandos que usa de forma interactiva también funcionan exactamente igual cuando se invocan en un contexto de script. Cualquier diferencia significativa en el comportamiento entre el uso interactivo y el uso programado creará una especie de disonancia cognitiva que es molesta para un usuario avanzado.

cpviene del comienzo de Unix. Estaba allí mucho antes de que se escribiera el estándar Posix. De hecho: Posix acaba de formalizar el comportamiento existente cpa este respecto.

Estamos hablando de la época (1970-01-01), cuando los hombres eran hombres de verdad, las mujeres eran mujeres de verdad y pequeñas criaturas peludas ... (estoy divagando). En esos días, agregar código adicional hacía que un programa fuera más grande. Ese fue un problema entonces, porque la primera computadora que ejecutó Unix fue una PDP-7 (¡actualizable a 144 KB de RAM!). Así que las cosas eran pequeñas, eficientes, sin características de seguridad.

Entonces, en esos días, tenía que saber lo que estaba haciendo, porque la computadora simplemente no tenía el poder para evitar que hiciera algo de lo que luego se arrepintió.

(Hay una bonita caricatura de Zevar; busque "zevar cerveaux assiste par ordinateur" para encontrar la evolución de la computadora. O pruebe http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- cointe.html durante el tiempo que exista)

Para aquellos realmente interesados ​​(vi algunas especulaciones en los comentarios): El original cpen el primer Unix era sobre dos páginas de código ensamblador (C vino más tarde). La parte relevante fue:

sys open; name1: 0; 0   " Open the input file
spa
  jmp error         " File open error
lac o17         " Why load 15 (017) into AC?
sys creat; name2: 0     " Create the output file
spa
  jmp error         " File create error

(Entonces, un duro sys creat)

Y, mientras estamos en eso: se utilizó la versión 2 de Unix (fragmento de código)

mode = buf[2] & 037;
if((fnew = creat(argv[2],mode)) < 0){
    stat(argv[2], buf);

que también es difícil creatsin pruebas ni salvaguardas. ¡Tenga en cuenta que el código C para V2 Unix cpes de menos de 55 líneas!

Debido a que estos comandos también están destinados a ser utilizados en scripts, posiblemente ejecutados sin ningún tipo de supervisión humana, y también porque hay muchos casos en los que realmente desea sobrescribir el objetivo (la filosofía de los shells de Linux es que el humano sabe qué ella está haciendo)

Todavía hay algunas salvaguardas:

• GNU cptiene un -n| --no-clobberopción
• Si copia varios archivos en uno solo, cpse quejará de que el último no es un directorio.

¿Es "hacer una cosa a la vez"?

Este comentario suena como una pregunta sobre un principio de diseño general. A menudo, las preguntas sobre estos son muy subjetivas, y no podemos escribir una respuesta adecuada. Tenga en cuenta que podemos cerrar preguntas en este caso.

A veces tenemos una explicación para la elección del diseño original, porque los desarrolladores han escrito sobre ellas. Pero no tengo una buena respuesta para esta pregunta.

¿Por qué cpestá diseñado de esta manera?

El problema es que Unix tiene más de 40 años.

Si estuviera creando un nuevo sistema ahora, podría hacer diferentes elecciones de diseño. Pero cambiar Unix rompería los scripts existentes, como se menciona en otras respuestas.

¿Por qué se cp diseñó para sobrescribir silenciosamente los archivos existentes?

La respuesta corta es "No sé" :-).

Comprende que ese cpes solo un problema. Creo que ninguno de los programas de comando originales está protegido contra la sobrescritura o eliminación de archivos. El shell tiene un problema similar al redirigir la salida:

$ cat first.html > second.html

Este comando también sobrescribe en silencio second.html.

Me interesa pensar cómo se podrían rediseñar todos estos programas. Puede requerir cierta complejidad adicional.

Creo que esto es parte de la explicación: los primeros Unix enfatizaron implementaciones simples . Para una explicación más detallada de esto, vea "peor es mejor", vinculado al final de esta respuesta.

Puede cambiar > second.htmlpara que se detenga con un error, si second.htmlya existe. Sin embargo, como hemos mencionado, a veces el usuario no desea reemplazar un archivo existente. Por ejemplo, puede estar construyendo un comando complejo, intentando varias veces hasta que haga lo que quiere.

El usuario podría correr rm second.htmlprimero si lo necesita. ¡Esto podría ser un buen compromiso! Tiene algunas posibles desventajas propias.

1. El usuario debe escribir el nombre de archivo dos veces.
2. Las personas también tienen muchos problemas para usar rm. Así que me gustaría hacer rmmás seguro también. ¿Pero cómo? Si hacemos rmmostrar cada nombre de archivo y le pedimos al usuario que confirme, ahora tiene que escribir tres líneas de comandos en lugar de una. Además, si tiene que hacer esto con demasiada frecuencia, se acostumbrará y escribirá "y" para confirmar sin pensar. Por lo tanto, podría ser muy molesto y aún podría ser peligroso.

En un sistema moderno, recomiendo instalar el trashcomando y usarlo en lugar de rmdonde sea posible. La introducción del almacenamiento de basura fue una gran idea, por ejemplo, para una PC gráfica de usuario único .

Creo que también es importante comprender las limitaciones del hardware original de Unix: RAM y espacio en disco limitados, salida mostrada en impresoras lentas , así como el sistema y el software de desarrollo.

Observe que el Unix original no tenía finalización de tabulación , para completar rápidamente un nombre de archivo para un rmcomando. (Además, el shell Bourne original no tiene historial de comandos, por ejemplo, como cuando usa la tecla de flecha hacia arriba bash).

Con la salida de impresora, se usaría editor basado en línea, ed. Esto es más difícil de aprender que un editor de texto visual. Debe imprimir algunas líneas actuales, decidir cómo desea cambiarlas y escribir un comando de edición.

Usar > second.htmles un poco como usar un comando en un editor de línea. El efecto que tiene depende del estado actual. (Si second.htmlya existe, su contenido será descartado). Si el usuario no está seguro del estado actual, se espera que se ejecute lso que ls second.htmlprimero.

"Implementación simple" como principio de diseño

Hay una interpretación popular del diseño de Unix, que comienza:

El diseño debe ser simple, tanto en la implementación como en la interfaz. Es más importante que la implementación sea simple que la interfaz. La simplicidad es la consideración más importante en un diseño.

...

Gabriel argumentó que "Peor es mejor" produjo un software más exitoso que el enfoque MIT: siempre que el programa inicial sea básicamente bueno, llevará mucho menos tiempo y esfuerzo implementarlo inicialmente y será más fácil adaptarse a nuevas situaciones. Portar software a nuevas máquinas, por ejemplo, se vuelve mucho más fácil de esta manera. Por lo tanto, su uso se extenderá rápidamente, mucho antes de que un [mejor] programa tenga la oportunidad de desarrollarse y desplegarse (ventaja de primer jugador).

https://en.wikipedia.org/wiki/Worse_is_better

El diseño de "cp" se remonta al diseño original de Unix. De hecho, había una filosofía coherente detrás del diseño de Unix, que ha sido un poco menos de lo que se ha referido en tono de broma como Peor-es-Mejor ^* .

La idea básica es que mantener el código simple es en realidad una consideración de diseño más importante que tener una interfaz perfecta o "hacer lo correcto".

• Simplicidad: el diseño debe ser simple, tanto en la implementación como en la interfaz. Es más importante que la implementación sea simple que la interfaz . La simplicidad es la consideración más importante en un diseño.

• Corrección: el diseño debe ser correcto en todos los aspectos observables. Es un poco mejor ser simple que correcto.

• Consistencia: el diseño no debe ser demasiado inconsistente. La consistencia se puede sacrificar por simplicidad en algunos casos, pero es mejor descartar aquellas partes del diseño que se ocupan de circunstancias menos comunes que introducir complejidad de implementación o inconsistencia.

• Integridad: el diseño debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubiertos. La integridad se puede sacrificar en favor de cualquier otra cualidad. De hecho, la integridad debe sacrificarse siempre que se ponga en peligro la simplicidad de implementación. La consistencia se puede sacrificar para lograr la integridad si se conserva la simplicidad; especialmente inútil es la consistencia de la interfaz.

^{( énfasis mío )}

Recordando que esto era 1970, el caso de uso de "Quiero copiar este archivo solo si aún no existe" habría sido un caso de uso bastante raro para alguien que realiza una copia. Si eso es lo que querías, serías capaz de verificar antes de la copia, y eso incluso puede ser programado.

En cuanto a por qué un sistema operativo con ese enfoque de diseño resultó ser el que ganó a todos los demás sistemas operativos que se construyeron en ese momento, el autor del ensayo también tenía una teoría para eso.

Un beneficio adicional de la filosofía de peor es mejor es que el programador está condicionado a sacrificar algo de seguridad, conveniencia y molestia para obtener un buen rendimiento y un uso modesto de los recursos. Los programas escritos con el enfoque de Nueva Jersey funcionarán bien tanto en máquinas pequeñas como en máquinas grandes, y el código será portátil porque está escrito sobre un virus.

Es importante recordar que el virus inicial tiene que ser básicamente bueno. Si es así, la propagación viral está asegurada siempre que sea portátil. Una vez que el virus se haya propagado, habrá presión para mejorarlo, posiblemente aumentando su funcionalidad más cerca del 90%, pero los usuarios ya han sido condicionados para aceptar algo peor que lo correcto. Por lo tanto, el software peor es mejor primero ganará aceptación, segundo condicionará a sus usuarios a esperar menos, y tercero mejorará a un punto que es casi lo correcto.

^{* - o lo que el autor, pero nadie más, llamó "El enfoque de Nueva Jersey"} .

La razón principal es que una GUI es, por definición, interactiva, mientras que un binario como /bin/cpes solo un programa al que se puede llamar desde todo tipo de lugares, por ejemplo desde su GUI ;-). Apuesto a que incluso hoy la gran mayoría de las llamadas /bin/cpno serán desde un terminal real con un usuario escribiendo un comando de shell, sino desde un servidor HTTP o un sistema de correo o un NAS. Una protección incorporada contra errores del usuario tiene mucho sentido en un entorno interactivo; menos en un binario simple. Por ejemplo, lo más probable es que su GUI llame /bin/cpen segundo plano para realizar las operaciones reales y ¡tenga que ocuparse de las preguntas de seguridad en la salida estándar a pesar de que solo le preguntó al usuario!

Tenga en cuenta que fue desde el primer día casi trivial escribir un envoltorio seguro /bin/cpsi así lo desea. La filosofía * nix es proporcionar bloques de construcción simples para los usuarios: de estos, /bin/cpes uno.