Чому `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. Якщо файл source_file має звичайний файл типу, слід зробити наступні кроки:

   3.а. Поведінка не визначено, якщо 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 (), визначеної в томі системних інтерфейсів 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; шукайте "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 полягає в тому, що людина знає, що s / він робить)

Є ще кілька гарантій:

• 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показати кожне ім’я файлу і попросимо користувача підтвердити, тепер він повинен написати три рядки команд замість одного. Крім того, якщо їй доводиться робити це занадто часто, вона ввійде в звичку і надумайте "y" для підтвердження, не замислюючись. Тож це може бути дуже дратівливим, а ще може бути небезпечним.

У сучасній системі я рекомендую встановити trashкоманду та використовувати її замість того, rmде це можливо. Впровадження сховища Trash було чудовою ідеєю, наприклад, для графічного ПК для одного користувача .

Я думаю, що також важливо розуміти обмеження оригінального обладнання 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, який трохи менше був , що напівжартома називають як гірше-це-Better ^* .

Основна ідея полягає в тому, що збереження коду простим - насправді важливіше розгляд дизайну, що мати ідеальний інтерфейс або "робити правильну річ".

• Простота - дизайн повинен бути простим, як в реалізації, так і в інтерфейсі. Важливо, щоб реалізація була простою, ніж інтерфейс . Простота - це найважливіша увага в дизайні.

• Правильність - дизайн повинен бути правильним у всіх спостережуваних аспектах. Трохи краще бути простим, ніж правильним.

• Консистенція - дизайн не повинен бути надмірно непослідовним. Послідовність може бути принесена в жертву для простоти в деяких випадках, але краще відмовитися від тих частин конструкції, які стосуються менш поширених обставин, ніж вводити або складність в реалізації, або невідповідність.

• Повнота - дизайн повинен охоплювати стільки важливих ситуацій, скільки є практичним. Усі обґрунтовано очікувані справи повинні бути висвітлені. Повноту можна принести в жертву на користь будь-якої іншої якості. Фактично, повнота повинна бути принесена у жертву, коли піддається небезпеці простота впровадження. Послідовність може бути принесена в жертву для досягнення повноти, якщо простота зберігається; Особливо марною є послідовність інтерфейсу.

^{( наголос мій )}

Пам'ятаючи, що це був 1970 рік, випадок використання "Я хочу скопіювати цей файл, лише якщо його вже не існує" був би досить рідкісним випадком використання для тих, хто виконує копію. Якщо це те, що ви хотіли, ви зможете перевірити його, перш ніж копіювати, і це навіть можна прописати.

Щодо того, чому ОС з таким дизайнерським підходом виявилася тією, яка перемогла над усіма іншими побудованими ОС у той час, автор реферату також мав теорію для цього.

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

Важливо пам’ятати, що початковий вірус повинен бути в основному хорошим. Якщо так, вірусне розповсюдження гарантується до тих пір, поки воно є портативним. Як тільки вірус пошириться, з’явиться тиск для його вдосконалення, можливо, збільшивши його функціональність ближче до 90%, але користувачі вже були обумовлені сприйняти гірше за потрібне. Тому програмне забезпечення, що гірше, краще - перше отримає прийняття, друге спричинить його очікування користувачів менше, а третє буде покращене до рівня, що є майже правильним.

^{* - або те, що автор, але ніхто інший, назвав «Підхід Нью-Джерсі»} .

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

Зауважте, що з першого дня, близького до тривіального, потрібно писати безпечну обгортку навколо, /bin/cpякщо так хочеться. Філософія * nix полягає у наданні простих будівельних блоків для користувачів: з них /bin/cpодна.