Почему `cp` предназначен для автоматической перезаписи существующих файлов? [закрыто]

Я проверил cpс помощью следующих команд:

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

Затем я копирую first.htmlв second.html:

$ cp first.html second.html

$ cat second.html
first

Файл second.htmlмолча перезаписывается без ошибок. Однако, если я сделаю это в графическом интерфейсе рабочего стола, перетащив файл с тем же именем, он будет добавлен first1.htmlавтоматически. Это позволяет избежать случайной перезаписи существующего файла.

Почему не cpследует этому шаблону вместо того, чтобы перезаписывать файлы без вывода сообщений?

Поведение перезаписи по умолчанию cpуказано в POSIX.

3. Если исходный_файл имеет тип обычный файл, должны быть предприняты следующие шаги:

   3.a. Поведение не определено, если dest_file существует и был записан на предыдущем шаге. В противном случае, если dest_file существует, должны быть предприняты следующие шаги:

   3.ai Если включена опция -i, утилита cp должна написать приглашение к стандартной ошибке и прочитать строку из стандартного ввода. Если ответ не является положительным, cp больше ничего не делает с source_file и переходит к любым оставшимся файлам.

   3.a.ii. Файловый дескриптор для dest_file должен быть получен путем выполнения действий, эквивалентных функции open (), определенной в томе системных интерфейсов POSIX.1-2017, вызываемому с использованием dest_file в качестве аргумента пути, и побитового ИЛИ для O_WRONLY и O_TRUNC в качестве офлаг аргумент.

   3.a.iii. Если попытка получить файловый дескриптор не удалась и включена опция -f, cp попытается удалить файл, выполнив действия, эквивалентные функции unlink (), определенной в томе System Interfaces POSIX.1-2017, который вызывается с помощью dest_file. в качестве аргумента пути. Если эта попытка завершится успешно, cp продолжит с шага 3b.

Когда была написана спецификация POSIX, уже существовало большое количество сценариев со встроенным допущением для поведения перезаписи по умолчанию. Многие из этих сценариев были разработаны для запуска без непосредственного участия пользователя, например, в качестве заданий cron или других фоновых задач. Изменение поведения сломало бы их. Просмотр и изменение их всех для добавления возможности принудительной перезаписи в любом месте, вероятно, считалось огромной задачей с минимальными преимуществами.

Кроме того, командная строка Unix всегда была разработана для того, чтобы опытный пользователь мог эффективно работать, даже за счет сложной кривой обучения для начинающего. Когда пользователь вводит команду, компьютер должен ожидать, что пользователь действительно это подразумевает, без каких-либо догадок; Пользователь обязан быть осторожным с потенциально разрушительными командами.

Когда была разработана оригинальная Unix, тогда системы имели настолько мало памяти и запоминающего устройства по сравнению с современными компьютерами, что перезаписывали предупреждения и подсказки, вероятно, рассматривались как расточительная и ненужная роскошь.

Когда был написан стандарт POSIX, прецедент был твердо установлен, и разработчики стандарта хорошо знали о достоинствах не нарушая обратную совместимость .

Кроме того, как уже описывали другие, любой пользователь может добавить / включить эти функции для себя, используя псевдонимы оболочки или даже создав cpкоманду замены и изменив их, $PATHчтобы найти замену перед стандартной системной командой, и таким образом получить защитную сеть, если желательно.

Но если вы сделаете это, вы обнаружите, что создаете опасность для себя. Если cpкоманда ведет себя одинаково при интерактивном использовании, а другая - при вызове из сценария, вы можете не помнить, что разница существует. В другой системе вы можете оказаться небрежным, потому что вы привыкли к предупреждениям и подсказкам в вашей собственной системе.

Если поведение в сценариях будет по-прежнему соответствовать стандарту POSIX, вы, вероятно, привыкнете к подсказкам в интерактивном режиме, а затем напишите сценарий, который выполняет массовое копирование, а затем обнаружите, что вы снова случайно что-то перезаписали.

Если вы также навязываете запросы в сценариях, что будет делать команда, когда она запускается в контексте, в котором нет пользователя, например, фоновых процессов или заданий cron? Будет ли скрипт зависать, прерываться или перезаписывать?

Зависание или прерывание означает, что задача, которая должна была быть выполнена автоматически, не будет выполнена. Отсутствие перезаписи может иногда также вызывать проблему само по себе: например, это может привести к тому, что старые данные будут дважды обрабатываться другой системой вместо их замены на обновленные данные.

Большая часть возможностей командной строки заключается в том, что как только вы узнаете, как что-то делать в командной строке, вы также будете неявно знать, как сделать это автоматически с помощью сценариев . Но это верно только в том случае, если команды, которые вы используете в интерактивном режиме, также работают точно так же, когда вызываются в контексте скрипта. Любые существенные различия в поведении между интерактивным использованием и использованием сценариев создадут своего рода когнитивный диссонанс, который раздражает опытного пользователя.

cpпроисходит от начала Unix. Это было задолго до того, как был написан стандарт Posix. Действительно: Posix только что формализовал существующее поведение cpв этом отношении.

Мы говорим об Эпохе (1970-01-01), когда мужчины были настоящими мужчинами, женщины были настоящими женщинами и пушистыми маленькими существами ... (Я отвлекся). В те дни добавление дополнительного кода делало программу больше. Тогда это было проблемой, потому что первым компьютером, на котором работал Unix, был PDP-7 (с возможностью обновления до 144 КБ ОЗУ!). Так что все было маленьким, эффективным, без функций безопасности.

Итак, в те дни вы должны были знать, что вы делаете, потому что у компьютера просто не было возможности помешать вам сделать то, о чем вы потом сожалели.

(Есть замечательный мультфильм Зевара; найдите «zevar cerveaux assiste par ordinateur», чтобы найти эволюцию компьютера. Или попробуйте http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- cointe.html пока он существует)

Для тех, кто действительно заинтересован (я видел некоторые предположения в комментариях): оригинал cpпервого Unix был около двух страниц кода на ассемблере (C появился позже). Соответствующая часть была:

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

(Итак, тяжело sys creat)

И пока мы работаем над этим: используется версия 2 Unix (фрагмент кода)

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

что также трудно creatбез тестов и гарантий. Обратите внимание, что C-код для V2 Unix cpсоставляет менее 55 строк!

Потому что эти команды также предназначены для использования в сценариях, возможно, выполняющихся без какого-либо человеческого контроля, а также потому, что существует множество случаев, когда вы действительно хотите перезаписать цель (философия оболочек Linux заключается в том, что человек знает, что она делает)

Есть еще несколько гарантий:

• GNU cpимеет -n| --no-clobberвариант
• если вы скопируете несколько файлов в один, cpто пожалуетесь, что последний не является каталогом.

Это "сделать одну вещь за один раз"?

Этот комментарий звучит как вопрос об общем принципе дизайна. Часто вопросы по этому поводу очень субъективны, и мы не можем дать правильный ответ. Имейте в виду, что в этом случае мы можем закрыть вопросы.

Иногда у нас есть объяснение первоначального выбора дизайна, потому что разработчики написали о них. Но у меня нет такого хорошего ответа на этот вопрос.

Почему cpтак устроено?

Проблема в том, что Unix старше 40 лет.

Если бы вы создавали новую систему сейчас, вы могли бы сделать другой выбор дизайна. Но изменение Unix сломало бы существующие сценарии, как упомянуто в других ответах.

Почему был cp разработан, чтобы молча перезаписать существующие файлы?

Краткий ответ: «Я не знаю» :-).

Поймите, что cpэто только одна проблема. Я думаю, что ни одна из оригинальных командных программ не защищена от перезаписи или удаления файлов. Оболочка имеет аналогичную проблему при перенаправлении вывода:

$ cat first.html > second.html

Эта команда также молча перезаписывает second.html.

Мне интересно подумать, как все эти программы могут быть переработаны. Это может потребовать дополнительной сложности.

Я думаю, что это часть объяснения: ранний Unix подчеркивал простые реализации . Более подробное объяснение этого см. В разделе «Чем хуже, тем лучше», ссылка на который приведена в конце этого ответа.

Вы можете изменить > second.htmlего, чтобы он остановился с ошибкой, если она second.htmlуже существует. Однако , как мы уже упоминали, иногда пользователь делает хочет заменить существующий файл. Например, она может создавать сложную команду, пытаясь несколько раз, пока она не сделает то, что она хочет.

Пользователь может запустить rm second.htmlпервым, если ему нужно. Это может быть хорошим компромиссом! У него есть некоторые возможные недостатки.

1. Пользователь должен дважды ввести имя файла.
2. Люди также получают много проблем с использованием rm. Поэтому я бы тоже хотел сделать его rmболее безопасным. Но как? Если мы rmпоказываем каждое имя файла и просим пользователя подтвердить, теперь она должна написать три строки команд вместо одной. Кроме того, если ей придется делать это слишком часто, она приобретет привычку и наберет «у», чтобы подтвердить, не задумываясь. Так что это может быть очень раздражающим и все же опасным.

В современной системе я рекомендую установить trashкоманду и использовать ее rmтам, где это возможно. Внедрение Trash Storage было отличной идеей, например, для однопользовательского графического ПК .

Я думаю, что также важно понимать ограничения оригинального оборудования Unix - ограниченное ОЗУ и дисковое пространство, вывод, отображаемый на медленных принтерах, а также на систему и программное обеспечение для разработки.

Обратите внимание, что в оригинальном Unix не было завершения табуляции , чтобы быстро заполнить имя файла для rmкоманды. (Кроме того, оригинальная оболочка Bourne не имеет истории команд, например, когда вы используете клавишу со стрелкой вверх bash).

При выводе на принтер вы бы использовали линейный редактор ed. Это сложнее освоить, чем визуальный текстовый редактор. Вы должны напечатать некоторые текущие строки, решить, как вы хотите их изменить, и ввести команду редактирования.

Использование > second.htmlнемного похоже на использование команды в редакторе строк. Эффект, который он оказывает, зависит от текущего состояния. (Если он second.htmlуже существует, его содержимое будет удалено). Если пользователь не уверен в текущем состоянии, он должен запускаться lsили ls second.htmlпервым.

«Простая реализация» как принцип проектирования

Существует популярная интерпретация Unix-дизайна, которая начинается с:

Дизайн должен быть простым, как по реализации, так и по интерфейсу. Для реализации важнее быть простым, чем интерфейс. Простота является наиболее важным фактором в дизайне.

...

Габриэль утверждал, что «Хуже лучше» создает более успешное программное обеспечение, чем подход MIT: пока первоначальная программа в основном хороша, ее реализация займет гораздо меньше времени и усилий, и ее будет легче адаптировать к новым ситуациям. Например, перенос программного обеспечения на новые машины становится намного проще. Таким образом, его использование будет быстро распространяться задолго до того, как [лучшая] программа получит шанс для разработки и развертывания (преимущество первопроходца).

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

Дизайн "cp" восходит к оригинальному дизайну Unix. На самом деле, за дизайном Unix стояла последовательная философия, которая была чуть менее шутливо названа « Хуже-лучше» ^* .

Основная идея заключается в том, что упрощение кода на самом деле является более важным соображением дизайна, чем идеальный интерфейс или «правильная работа».

• Простота - дизайн должен быть простым, как по реализации, так и по интерфейсу. Для реализации важнее быть простым, чем интерфейс . Простота является наиболее важным фактором в дизайне.

• Правильность - дизайн должен быть правильным во всех наблюдаемых аспектах. Немного лучше быть простым, чем правильным.

• Согласованность - дизайн не должен быть чрезмерно непоследовательным. В некоторых случаях согласованность может быть принесена в жертву для простоты, но лучше отбросить те части проекта, которые имеют дело с менее распространенными обстоятельствами, чем вводить либо сложность реализации, либо несогласованность.

• Полнота - дизайн должен охватывать столько важных ситуаций, сколько это практически возможно. Все разумно ожидаемые случаи должны быть покрыты. Полнота может быть принесена в жертву в пользу любого другого качества. Фактически, полнота должна быть принесена в жертву всякий раз, когда простота реализации находится под угрозой. Последовательность может быть принесена в жертву для достижения полноты, если простота сохраняется; Особенно бесполезна последовательность интерфейса.

^{( акцент мой )}

Помня, что это был 1970 год, вариант использования «Я хочу скопировать этот файл, только если он еще не существует» был бы довольно редким случаем для кого-то, кто выполняет копирование. Если это то, что вы хотели, вы вполне могли бы проверить перед копированием, и это можно даже записать в сценарии.

Что касается того, почему ОС с таким подходом к проектированию оказалась той, которая одержала победу над всеми другими ОС, создаваемыми в то время, у автора эссе также была теория для этого.

Еще одно преимущество философии «хуже - лучше» заключается в том, что программист вынужден жертвовать некоторой безопасностью, удобством и хлопотами, чтобы получить хорошую производительность и скромное использование ресурсов. Программы, написанные с использованием подхода Нью-Джерси, будут хорошо работать как на небольших, так и на больших машинах, а код будет переносимым, поскольку он написан поверх вируса.

Важно помнить, что первоначальный вирус должен быть в основном хорошим. Если это так, то распространение вируса гарантировано, пока оно переносимо. Как только вирус распространился, возникнет необходимость в его улучшении, возможно, за счет увеличения его функциональности ближе к 90%, но пользователи уже были готовы принять худшее, чем нужно. Таким образом, программное обеспечение «хуже-лучше» сначала получит признание, второе заставит пользователей ожидать меньшего, а третье будет улучшено до уровня, который является почти правильным.

^{* - или то, что автор, но никто другой, назвал «подход Нью-Джерси»} .

Основная причина в том, что графический интерфейс по определению является интерактивным, в то время как двоичный код /bin/cp- это просто программа, которую можно вызывать из любого места, например из вашего графического интерфейса ;-). Могу поспорить, что даже сегодня подавляющее большинство звонков /bin/cpбудет поступать не с реального терминала, где пользователь вводит команду оболочки, а с HTTP-сервера, почтовой системы или NAS. Встроенная защита от ошибок пользователя имеет смысл в интерактивной среде; меньше так в простом бинарном файле. Например, ваш GUI, скорее всего, будет вызывать /bin/cpв фоновом режиме для выполнения реальных операций, и ему придется иметь дело с вопросами безопасности на стандартном out, даже если он только что спросил пользователя!

Обратите внимание, что с первого дня было почти тривиально написать безопасную оболочку, /bin/cpесли это необходимо. Философия * nix заключается в предоставлении пользователям простых строительных блоков: один из них /bin/cp.