Переміщено / вміст біна в / usr / bin, можливо скасувати?

Запускаючи Ubuntu 17.04, я встановлював програмне забезпечення з нерепозиторного розповсюдження, я повинен був перемістити вміст папки програмного забезпечення в / usr / bin (що вже було порадою)

Це один із тих днів, і що я зробив замість цього:

mv /bin/* /usr/bin

Тому я накрутив і випадково перемістив усі файли у скриньці до / usr / bin та / bin був порожнім. Оскільки я вважаю, що / бін є критично важливим для системи, для швидкого усунення я скопіював / usr / bin вміст у / bin.

Тепер вміст my / bin та / usr / bin однаковий, і обидва містять файли, спочатку в / bin та / usr / bin.

1. Чи зараз мій Ubuntu перерваний? (Ще не намагалися перезавантажити комп’ютер, зараз все, здається, все ще працює)
2. Чи є спосіб дізнатися, які файли були переміщені / скопійовані в / usr / bin останнім часом, тож я міг просто вручну подбати про ситуацію? 2.1 Чи зазвичай файли, що перекриваються, / bin та / usr / bin
3. Чи є інші способи скасувати те, що я зробив?

У мене не встановлено Timeshift, тому відновлення резервних копій не є варіантом, але в даний час на комп’ютері немає нічого критичного, тому я міг би просто визнати, що за допомогою програмного забезпечення слід встановити весь Linux-розділ.

Чи зараз мій Ubuntu перерваний?

Так, ваша Ubuntu зламана

Ви зіпсували щось важливе для управління пакетами .

Тож на практиці створюйте резервні копії важливих даних (принаймні /etcта /home), можливо, також і список встановлених пакетів, наприклад, вихід dpkg -lта перевстановлення Ubuntu.

^{(новачок може спробувати керувати - як у інших відповідях - але тоді він не зробив би такої величезної та основної помилки)}

Я міг би просто визнати, що за допомогою програмного забезпечення слід переустановити весь Linux-розділ.

Це, мабуть, те, що би зайняло менше вашого часу. Утримання вашої нинішньої системи за допомогою інших відповідей - це утримання її в дуже безладному стані (що може принести вам майбутні головні болі).

Оскільки ви переформатуєте свій диск, подумайте про введення /homeокремого розділу (тому майбутні такі помилки не втратять ваші дані). Перш ніж робити це, надрукуйте на папері вихід df -hта df -hiта fdisk -l(вони дають інформацію про місце на диску -на використаний та доступний- ...). Будьте розумні мати достатньо великий системний розділ (коренева файлова система); якщо ви можете собі це дозволити 100 Гбайт, більш ніж достатньо.

Я повинен був перемістити вміст папки програмного забезпечення у / usr / bin

(термінологія: У Unix є каталоги, а не "папки").

Це ( переїзд до /usr/bin/) дуже неправильно. Або поліпшити свій $ PATH (переважно) або в більшості додатків сімлінок в /usr/bin/і переважно перемістити (або символічні посилання) виконувані /usr/local/bin/.

Мудрий підхід до ніколи не зміниться /usr/bin/, /bin, /sbin, /usr/sbin/ за межами інструментів управління пакетами (наприклад dpkg, apt-get, aptitudeі т.д. ...). Прочитайте FHS .

У Linux (і в більшості інших систем, хоча POSIX не дає вам гарантії, якщо переїзд не відбудеться через файлові системи), це оновило б їх час, тому припустимо, що жодна з інших /usr/binне торкнулася протягом останніх 24 годин , ви повинні мати можливість перемістити їх назад за допомогою:

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

Видаліть, echoякщо це виглядає правильно. Зауважте, що ви не зможете відновити файли, що існували з тим самим іменем у /binта /usr/bin(оригінальні файли в програмі /usr/binбули б втрачені)

Потенційний застереження: якщо деякі файли були жорстко пов'язані в обох, /binі /usr/binвсі жорсткі посилання в /usr/binних будуть переміщені /bin.

Тепер, ви можете думати , що , так як /binі /usr/binв за замовчуванням $PATH, і /binдоступний за /bootпринаймні , до того /usrвстановлено, він не повинен незалежно від того , що виконувані файли знаходяться в /binзамість /usr/bin.

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

#! /usr/bin/env bash

не вийде працювати після вас mv /usr/bin/env /bin/env. У зв'язку з цим наявність команд в обох місцях безпечніше, оскільки вона не порушує ці сценарії.

1. Ваша установка має бути в основному гаразд; не повинно бути різних файлів з тим самим іменем у ( /usrта /usr/bin(що відповідає вашим 2.1), тому маючи всі файли в обох /binі /usr/binнічого не порушуйте (доки не оновите пакети). Єдина проблема, яка може виникнути зараз, - це зламані символьні посилання, якщо ви перезаписали бінарний файл із символьним посиланням на нього. Щоб виправити це, шукайте зламані символьні посилання:

   find -L /bin /usr/bin -type l -ls
   

   і перевстановіть будь-які пакунки, що відповідають переліченим файлам (наприклад, якщо він /usr/bin/zshвідображається як зламаний, dpkg -S /bin/zsh /usr/bin/zshпідкаже, з якого пакета прийшов файл; перевстановіть його apt --reinstall install zsh).

2. Ви можете показати та сортувати за ctime, щоб побачити файли, які нещодавно були змінені (які включатимуть переміщені файли):

   ls -ltc /bin
   

3. Найкращим підходом до скасування того, що ви зробили, є використання cruftпакету та видалення файлів, які він знаходить, /binабо /usr/binякі не надходять із пакета:

   sudo apt install cruft
   sudo cruft -d "/ /usr"
   

   якщо тільки файли не є посиланнями на файли в /etc/alternatives(у такому випадку ви повинні залишити їх у спокої).

Можливо, розробити лише те, чому ваша система більшою чи меншою мірою "зламана".

1. Як вказує @ basile-starynkevitch, система управління пакунками може бути дуже заплутана, якщо вона знайде бінарні файли, /binколи вони повинні бути /usr/bin, і навпаки.
2. Деякі (можливо важливі) сценарії можуть бути важко провідними для того, щоб знайти певний бінарний файл в одній або іншій каталозі (за деяких обставин це добра практика, наприклад, з точки зору безпеки, не покладатися на вміст цього документа $PATH).
3. Причина , чому існує різниця між /binі в /usr/binтому , що перший може потенційно бути на перегородці , яка встановлена на більш ранній стадії завантаження. У цьому контексті (тобто під час завантаження системи) не тільки /bin/xxxбінарні файли, ймовірно, посилаються на повний шлях, але каталог /usr/binможе бути недоступним у системі в той момент. (Якщо ви df /binі df /usr/bin, можливо, ви бачите одну і ту ж перелічену файлову систему або різні; можливо, більшість встановлених за замовчуванням цих днів залиште обидва каталоги в одному розділі).

Таким чином , ви можете doubless бачити , що якщо у вас є такі ж виконавчі файли в обох /binі /usr/bin, потім проблеми 2 і 3 не відбуватиметься, і збиток від 1 , може бути незначним. Наприклад, Re 1, наприклад, пакети можуть бути неправильно видалені, якщо ви намагаєтесь їх видалити; і оновлення може стати схильним, якщо оновлення намагається оновити копію в "правильному" місці, але ігнорує копію в "неправильному" місці. Таким чином, якщо вищевказані кошти здаються занадто різкими або складним, ви могли б піти з залишенням системи в цьому стані.

Але якщо це важлива система, я дійсно не став би на цьому базитися.

Загальне правило (знову повторюється @ basile-starynkevitch) - ніколи не мавпати з друзями /usr/bin, /binа друзі - вони «належать» до розповсюдження - і пакет, який пропонує зробити це як частину його звичайної установки, - це не гарний пакет.

Редагувати: Відповідно до пункту 3, в контексті systemd / Fedora та друзів обговорюється питання, чому є сенс перемістити весь вміст /binна /usr/bin, а також позначити посилання першого та другого. Це не рекомендація, що ви робите це самостійно - ця сторінка адресована людям, які здійснюють розповсюдження, - але вона містить деяку історію того, чому існує ця відмінність (і, як наслідок, чому це тепер просто запилена традиція).