/ binの内容を/ usr / binに移動し、元に戻すことができますか？

Ubuntu 17.04を実行して、非リポジトリディストリビューションからソフトウェアをインストールしていました。ソフトウェアbin -folderの内容を/ usr / binに移動することになっていました（これはすでにわかりにくいアドバイスでした）

それは当時の一つなので、私が代わりにしたこと：

mv /bin/* /usr/bin

だから私はめちゃくちゃにして、誤ってbin内のすべてのファイルを/ usr / binに移動しましたが、/ binは空でした。/ binはシステムに不可欠であると考えているため、迅速な対処のために、/ usr / binの内容を/ binにコピーしました。

これで、/ binと/ usr / binの内容は同じになり、両方とも元々/ binと/ usr / binに分離されたファイルが含まれます。

1. 現在、Ubuntuは壊れた状態ですか？（まだコンピューターを再起動しようとしませんでした、今はすべてがまだ動作しているようです）
2. どのファイルが最近/ usr / binに移動/コピーされたかを知る方法はありますか？2.1通常、/ binと/ usr / binに重複するファイルがありますか
3. 私がしたことを元に戻す他の方法はありますか？

私はタイムシフトをインストールしていないので、バックアップの復元はオプションではありませんが、現在のコンピューターには重要なものは何もありません。

現在、Ubuntuは壊れた状態ですか？

はい、Ubuntuが壊れています

パッケージ管理にとって重要な何かを台無しにしました。

したがって、実際には、重要なデータ（少なくとも/etcおよび/home）をバックアップします。おそらく、インストールされたパッケージのリスト（例：の出力）をバックアップし、dpkg -lUbuntuを再インストールします。

^{（初心者でも他の回答と同じように管理しようとすることはできますが、そうすれば彼はそのような大きな基本的な間違いをしなかったでしょう）}

Linuxパーティション全体を再インストールすることを認めることができます。

それはおそらくあなたの時間をより少なく消費するものです。他の回答を利用して現在のシステムを維持することは、システムを非常に乱雑な状態に保つことです（これは将来の頭痛の種になります）。

ディスクを再フォーマットするので/home、別のパーティションに入れることを検討してください（将来そのような間違いがデータを失わないように）。紙に印刷する前に、df -hand df -hiおよびfdisk -l（ディスク容量に関する情報を提供します-使用済みおよび使用可能の両方-...）。システムパーティション（ルートファイルシステム）を十分に大きくするのが賢明です。余裕があれば100Gバイトで十分です。

ソフトウェアbin -folderの内容を/ usr / binに移動することになっていた

（用語：Unixにはディレクトリがあり、「フォルダ」はありません）。

それは、（移動する/usr/bin/）は非常に間違っています。$ PATHを改善する（できれば）か、せいぜいsymlinksを追加して/usr/bin/、できればに実行可能ファイルを移動（またはsymlinksを追加）してください/usr/local/bin/。

賢明なアプローチは、変更しないことです/usr/bin/、/bin、/sbin、/usr/sbin/ パッケージ管理ツールの外（例えばdpkg、apt-get、aptitude、など...）。FHSをお読みください。

Linux（および他のほとんどのシステムでは、POSIXはファイルシステム間を移動しない限りその保証を提供しませんが）、ctimeを更新するため/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. インストールはほとんど問題ないはずです。/usrand /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. 一部の（おそらく重要な）スクリプトは、1つのディレクトリまたは他のディレクトリで特定のバイナリを見つけるために固定されている場合があります（状況によっては、セキュリティの観点などから、の内容に依存しないことをお勧めし$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のコンテキストで、/bintoのすべてのコンテンツを移動し/usr/bin、1番目を2番目にシンボリックリンクすることが理にかなっている理由についての議論があります。これは、自分でこれを行うことを推奨するものではありません（そのページは配布を行う人に宛てられています）。