Le contenu de / bin a été déplacé vers / usr / bin, il est possible d'annuler?

Sous Ubuntu 17.04, j'installais un logiciel à partir d'une distribution non référentielle, je devais déplacer le contenu du dossier du logiciel vers / usr / bin (ce qui était déjà un conseil)

C'est un de ces jours, alors ce que j'ai fait à la place:

mv /bin/* /usr/bin

J'ai donc foiré et j'ai accidentellement déplacé tous les fichiers du bac vers / usr / bin et / bin était vide. Comme je considère que / bin est critique pour le système, pour y remédier rapidement, j'ai copié le contenu de / usr / bin dans / bin.

Maintenant, mon contenu / bin et / usr / bin sont identiques et contiennent tous les deux les fichiers à l'origine dans / bin et / usr / bin séparés.

1. Mon Ubuntu est-il en panne maintenant? (N'a pas encore essayé de redémarrer l'ordinateur, en ce moment tout semble toujours fonctionner)
2. Existe-t-il un moyen de savoir quels fichiers ont été déplacés / copiés vers / usr / bin le plus récemment, afin que je puisse simplement gérer manuellement la situation? 2.1 Y a-t-il généralement des fichiers qui se chevauchent dans / bin et / usr / bin
3. Y a-t-il d'autres façons d'annuler ce que j'ai fait?

Je n'ai pas installé Timeshift, donc la restauration des sauvegardes n'est pas une option, mais il n'y a actuellement rien de critique sur l'ordinateur, donc je pourrais juste admettre de bousiller réinstaller toute la partition linux.

Mon Ubuntu est-il en panne maintenant?

Oui, votre Ubuntu est cassé

Vous avez gâché quelque chose d'important pour la gestion des packages .

Donc, dans la pratique, sauvegardez vos données importantes (au moins /etcet /home), peut-être aussi la liste des packages installés, par exemple la sortie de dpkg -l, et réinstallez Ubuntu.

^{(un non-novice pourrait essayer de gérer - comme dans d'autres réponses -, mais il n'aurait pas fait une erreur aussi énorme et fondamentale)}

Je pourrais juste admettre de bousiller réinstaller toute la partition Linux.

C'est probablement ce qui consommerait moins de votre temps. Garder votre système actuel à l'aide d'autres réponses, c'est le garder dans un état très désordonné (ce qui vous donnerait de futurs maux de tête).

Puisque vous reformatez votre disque, envisagez de placer /homeune partition distincte (afin que de telles erreurs futures ne perdent pas vos données). Avant de faire cela, imprimez sur papier la sortie de df -het df -hiet fdisk -l(ils donnent des informations sur l'espace disque -les deux utilisés et disponibles- ...). Soyez sage d'avoir une partition système suffisamment grande (le système de fichiers racine); si vous pouvez vous le permettre, 100 Go sont plus que suffisants.

Je devais déplacer le contenu du dossier du logiciel bin vers / usr / bin

(terminologie: Unix a des répertoires, pas des "dossiers").

Cela ( passer à /usr/bin/) est très faux. Améliorez votre $ PATH (de préférence) ou tout au plus ajoutez des liens symboliques dans /usr/bin/et de préférence déplacez (ou ajoutez des liens symboliques) aux exécutables /usr/local/bin/.

L'approche sage est de ne jamais changer /usr/bin/, /bin, /sbin, en /usr/sbin/ dehors des outils de gestion des paquets (par exemple dpkg, apt-get, aptitude, etc ...). Lisez le FHS .

Sous Linux (et sur la plupart des autres systèmes, bien que POSIX ne vous donne pas cette garantie à moins que le déplacement n'ait eu lieu sur les systèmes de fichiers), cela aurait mis à jour leur heure de connexion, donc en supposant qu'aucun des autres /usr/binn'a été touché au cours des dernières 24 heures , vous devriez pouvoir les reculer avec:

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

Retirez le echosi cela vous semble correct. Notez que vous ne pourrez pas récupérer les fichiers qui existaient sous le même nom dans /binet /usr/bin(ceux d'origine dans /usr/binauraient été perdus)

Une mise en garde potentielle: si certains fichiers étaient liés en dur dans les deux /binet /usr/bin, tous les liens en dur /usr/binseraient déplacés vers /bin.

Maintenant, vous pouvez penser que puisque /binet /usr/binsont dans la valeur par défaut $PATH, et /binest disponible /bootau moins avant le /usrmontage, peu importe que les exécutables soient à la /binplace de /usr/bin.

Mais ce serait ignorer que de nombreuses commandes codent en dur les chemins des exécutables et s'attendent à ce qu'elles le soient dans certains cas spécifiques. Un cas commun est la frange. Tous les scripts qui ont:

#! /usr/bin/env bash

ne fonctionnera pas après vous mv /usr/bin/env /bin/env. À cet égard, avoir les commandes dans les deux emplacements est plus sûr car il ne cassera pas ces scripts.

1. Votre installation devrait être en grande partie OK; il ne devrait pas y avoir de fichiers différents avec le même nom dans /usret /usr/bin(qui répond à votre 2.1), donc avoir tous les fichiers dans les deux /binet /usr/binne cassera rien (jusqu'à ce que vous mettiez à jour les packages). Le seul problème que vous pourriez avoir maintenant est celui des liens symboliques cassés, si vous avez remplacé un binaire par un lien symbolique. Pour résoudre ce problème, recherchez les liens symboliques rompus:

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

   et réinstallez tous les packages correspondant aux fichiers répertoriés (par exemple, s'il /usr/bin/zshapparaît comme cassé, dpkg -S /bin/zsh /usr/bin/zshvous indiquera de quel package provient le fichier; réinstallez-le avec apt --reinstall install zsh).

2. Vous pouvez afficher et trier par ctime pour voir les fichiers qui ont été récemment modifiés (qui incluront les fichiers que vous avez déplacés):

   ls -ltc /bin
   

3. La meilleure approche pour annuler ce que vous avez fait est d'utiliser le cruftpackage et de supprimer les fichiers qu'il trouve /binou /usr/binqui ne proviennent pas d'un package:

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

   sauf si les fichiers sont des liens symboliques vers des fichiers dans /etc/alternatives(auquel cas vous devez les laisser seuls).

Il peut être instructif d'expliquer pourquoi votre système est, dans une plus ou moins grande mesure, «cassé».

1. Comme le souligne @ basile-starynkevitch, le système de gestion des packages a le potentiel de devenir très confus s'il trouve des fichiers binaires /binquand ils devraient l'être /usr/bin, et vice versa.
2. Certains scripts (peut-être importants) peuvent être câblés pour trouver un binaire particulier dans un répertoire ou dans l'autre (dans certaines circonstances, c'est une bonne pratique, par exemple du point de vue de la sécurité, de ne pas se fier au contenu du $PATH).
3. La raison pour laquelle il existe une distinction entre /binet /usr/binest que la première peut potentiellement se trouver sur une partition qui est montée à un stade antérieur du démarrage. Dans ce contexte (c'est-à-dire lors du démarrage du système), non seulement les /bin/xxxbinaires seraient probablement référencés par un chemin complet, mais le répertoire /usr/binpourrait ne pas être disponible sur le système à ce stade. (Si vous df /binet df /usr/bin, vous pouvez voir le même système de fichiers répertorié, ou différents; probablement la plupart des installations par défaut, de nos jours, laissez les deux répertoires dans la même partition).

Ainsi, vous pouvez doubler voir que, si vous avez les mêmes binaires dans les deux /binet /usr/bin, alors les problèmes 2 et 3 ne se produiront pas, et les dégâts de 1 pourraient être mineurs. Par exemple, les packages peuvent ne pas être correctement désinstallés si vous essayez de les supprimer; et les mises à niveau peuvent se brouiller si la mise à niveau tente de mettre à niveau la copie au bon endroit, mais ignore la copie au mauvais endroit. Ainsi, si les remèdes ci-dessus semblent trop drastiques ou compliqués, vous pourriez vous en sortir en laissant le système dans cet état.

Mais s'il s'agit d'un système important, je ne miserais vraiment pas là-dessus.

Une règle générale (faisant écho à @ basile-starynkevitch) est de ne jamais faire de singe avec /usr/bin, /binet amis - ils `` appartiennent '' à la distribution - et un paquet qui suggère de le faire dans le cadre de son installation normale n'est ... pas un bon paquet.

Edit: Relevant du point 3, il y a une discussion dans le contexte de systemd / Fedora et ses amis pour savoir pourquoi il est logique de déplacer tout le contenu de /binvers /usr/binet de créer un lien symbolique entre le premier et le second. Ce n'est pas une recommandation que vous le fassiez vous-même - cette page s'adresse aux personnes qui font des distributions - mais elle comprend un historique des raisons pour lesquelles cette distinction existe (et implicitement pourquoi elle est maintenant simplement une tradition poussiéreuse).