/binの内容を/usr/binに移動しましたが、キャンセルできますか？

/usr/binLinux（および他のほとんどのシステムではファイルシステム間の移動がない限り、POSIXはこの保証を提供しませんが）ではctimeが更新されるため、過去24時間に他のシステムにアクセスしたことがないと仮定すると、次のことができます。次を介して戻ります。

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

echo正しいと思われる場合は削除してください。/binに存在するのと同じ名前のファイルは回復できませんので注意してください。/usr/bin（元のファイルは/usr/bin失われます。）

/bin1つの潜在的な注意：一部のファイルがおよびからすべてのハードリンクになっている場合は、/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。これに関して、コマンドを2つの場所に置くことはスクリプトを壊さないので、より安全です。

私のUbuntuは今破損していますか？

はい、Ubuntuが故障しました

重要なことを台無しにしたパッケージ管理。

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

^{（初心者ではない人は他の答えのように管理しようとするかもしれませんが、それほど大きくて基本的な間違いを犯すことはありません）}

私は完全なLinuxパーティションを台無しにすることを認めることができます。

時間がかかりません。他の回答の助けを借りて現在のシステムを維持すると、システムは非常に混乱しています（これは将来の問題を引き起こす可能性があります）。

ディスクを再フォーマットしているため、別々/homeのパーティションを配置することをお勧めします（将来このようなエラーによってデータが失われないように）。これを行う前に、印刷したdf -h用紙を印刷してください（使用されているディスク容量と利用可能なディスク容量に関する情報を提供しています...）。余裕がある場合は、十分に大きなシステムパーティション（ルートファイルシステム）を持つことが賢明です。df -hifdisk -l

ソフトウェアbinフォルダの内容を/usr/binに移動する必要がありますか？

（用語：Unixには「フォルダ」ではないディレクトリがあります）。

それ（移動する）/usr/bin/非常に間違っています。あなたの$パス（最高）または最も多く追加されましたシンボリックリンクそして/usr/bin/好ましくは、実行可能ファイルを/usr/local/bin/。

/usr/bin/パッケージ管理ツール（たとえば、など）の外部では変更しないことをお勧めします。読む/bin/sbin/usr/sbin/dpkgapt-getaptitudeFHS。

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. /bin@basile-starynkevitchが指摘したように、パッケージ管理システムが必要な場所でバイナリを見つけるか、/usr/binその逆の場合は非常に混乱する可能性があります。
2. 一部の（潜在的に重要な）スクリプトは、ハードリンクを介してあるディレクトリまたは別のディレクトリに特定のバイナリを見つけることができます（これはいくつかのケースでは良い方法です。たとえば、セキュリティの観点からは、いいえ）の内容によって異なります$PATH。
3. /binとの違いは、/usr/bin電子がブートの初期段階でマウントされたパーティションにある可能性があるためです。この場合（つまり、システムの起動時に）フルパスで/bin/xxxバイナリを参照できるだけでなく、その時点でシステム/usr/binでディレクトリを使用できない可能性があります。 （df /binおよび場合は、df /usr/bin同じファイルシステムまたは異なるファイルシステムが一覧表示されることがあります。最近、ほとんどのデフォルトインストールでは、両方のディレクトリを同じパーティションに保持できます。）

だから、同じ/bin、にすべてバイナリがあると/usr/bin問題2、3は発生せず、問題1によるダメージは最小化される可能性が高いです。たとえば、Re 1でパッケージを削除しようとするとパッケージが正しく削除されない可能性があり、アップグレードが「正しい」場所にあるコピーをアップグレードしようとしましたが、「間違った」場所にあるコピーを無視するとアップグレードが壊れる。 。したがって、上記の解決策が過度に過度または複雑に見える場合可能この状態でシステムをそのままにしてください。

しかし、これが重要なシステムであれば、本物私はそれを信じていません。

/usr/bin一般的な規則（再度@basile-starynkevitchを反映する）は、および友達（彼らはディストリビューションに「属しています」）と通常のインストールの一部としてこれを行うために推奨されるパッケージをむしろ扱わないことです/bin。ソフトウェアパッケージ。

編集する：ポイント3に関しては以下があります。systemd / Fedoraと友達の文脈での議論/binすべてを最初のコンテンツに移動し/usr/bin、2番目のコンテンツにシンボリックリンクするのはなぜ意味がありますか？これはいいえこの作業は直接行うことをお勧めします。このページはdistroユーザーのために書かれています。しかし、これには、このような区別が存在する理由のいくつかの歴史が含まれています（そしてこれが今はほんの少しだけですが、積み重ねられた伝統である理由のヒントも含まれています）。