Movido o conteúdo / bin para / usr / bin, é possível desfazer?

Executando o Ubuntu 17.04, eu estava instalando um software a partir da distribuição não-repositório, eu deveria mover o conteúdo da pasta bin do software para / usr / bin (que já era um conselho duvidoso)

É um daqueles dias, então o que eu fiz:

mv /bin/* /usr/bin

Então eu estraguei tudo e acidentalmente movi todos os arquivos no bin para / usr / bin e / bin estava vazio. Como considero que / bin é crítico para o sistema, para uma solução rápida, copiei o conteúdo / usr / bin para / bin.

Agora meu conteúdo / bin e / usr / bin é idêntico e ambos contêm os arquivos originalmente em / bin e / usr / bin separados.

1. Meu Ubuntu está em um estado quebrado agora? (Ainda não tentou reiniciar o computador, agora tudo parece ainda funcionar)
2. Existe uma maneira de saber quais arquivos foram movidos / copiados para / usr / bin mais recentemente, para que eu pudesse cuidar manualmente da situação? 2.1 Normalmente existem arquivos sobrepostos em / bin e / usr / bin
3. Existem outras maneiras de desfazer o que fiz?

Eu não tenho o Timeshift instalado, portanto, restaurar backups não é uma opção, mas não há nada crítico no computador atualmente, então eu poderia admitir que estrague a reinstalação de toda a partição linux.

Meu Ubuntu está em um estado quebrado agora?

Sim, seu Ubuntu está quebrado

Você estragou algo importante para o gerenciamento de pacotes .

Portanto, na prática, faça backup de seus dados importantes (pelo menos /etce /home), talvez também a lista de pacotes instalados, por exemplo, saída do dpkg -le reinstale o Ubuntu.

^{(um não iniciante poderia tentar gerenciar - como em outras respostas -, mas não teria cometido um erro tão grande e básico)}

Eu poderia apenas admitir que estrague a reinstalação de toda a partição linux.

Isso é provavelmente o que consumiria menos do seu tempo. Manter o sistema atual com a ajuda de outras respostas é mantê-lo em um estado muito confuso (o que causaria dores de cabeça futuras).

Como você está reformatando seu disco, considere colocar /homeuma partição separada (para que futuros erros desse tipo não percam seus dados). Antes de fazer isso, imprima em papel a saída de df -he df -hie fdisk -l(eles fornecem informações sobre o espaço em disco - ambos usados ​​e disponíveis - ...). Seja prudente em ter uma partição de sistema suficientemente grande (o sistema de arquivos raiz); se você puder pagar, 100 Gbytes é mais que suficiente.

Eu deveria mover o conteúdo da pasta bin do software para / usr / bin

(terminologia: o Unix possui diretórios, não "pastas").

Isso ( mudar para /usr/bin/) está muito errado. Quer melhorar o seu $ PATH (de preferência) ou na maioria dos add links simbólicos em /usr/bin/e de preferência mover (ou adicionar links simbólicos) executáveis /usr/local/bin/.

A abordagem sensata é a de nunca alteração /usr/bin/, /bin, /sbin, /usr/sbin/ fora de ferramentas de gerenciamento de pacotes (por exemplo dpkg, apt-get, aptitude, etc ...). Leia a ESF .

No Linux (e na maioria dos outros sistemas, embora o POSIX não lhe ofereça essa garantia, a menos que a movimentação /usr/bintenha ocorrido nos sistemas de arquivos), isso teria atualizado seu tempo de execução, assumindo que nenhum dos outros foi tocado nas últimas 24 horas , você poderá movê-los de volta com:

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

Remova o echoque parece certo. Observe que você não poderá recuperar os arquivos que existiam com o mesmo nome /bine /usr/bin(os originais /usr/binteriam sido perdidos)

Uma ressalva em potencial: se alguns arquivos tiverem um link físico fixo nos dois /bine /usr/bin, todos os links /usr/binfísicos serão movidos para /bin.

Agora, você pode pensar que uma vez /bine /usr/binestão no padrão $PATH, e /binestá disponível em /bootpelo menos antes /usré montado, ele deve não importa se os executáveis estão em /binvez de /usr/bin.

Mas isso ignoraria que muitos comandos codificam os caminhos dos executáveis ​​e esperam que eles estejam em algum caso específico. Um caso comum é a franja. Todos os scripts que possuem:

#! /usr/bin/env bash

falhará ao trabalhar depois de você mv /usr/bin/env /bin/env. Nesse sentido, ter os comandos nos dois locais é mais seguro, pois não quebrará esses scripts.

1. Sua instalação deve estar boa; não deve haver arquivos diferentes com o mesmo nome em /usre /usr/bin(que responde ao seu 2.1), portanto, ter todos os arquivos nos dois /bine /usr/binnão quebrará nada (até você atualizar os pacotes). O único problema que você pode ter agora são links simbólicos quebrados, se você substituir um binário por um link simbólico. Para corrigir isso, procure links simbólicos quebrados:

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

   e reinstale todos os pacotes correspondentes aos arquivos listados (por exemplo, se /usr/bin/zshaparecer como quebrado, dpkg -S /bin/zsh /usr/bin/zshinformará de qual pacote o arquivo veio; reinstale-o com apt --reinstall install zsh).

2. Você pode mostrar e classificar por ctime para ver os arquivos que foram alterados recentemente (que incluirão os arquivos que você moveu):

   ls -ltc /bin
   

3. A melhor abordagem para desfazer o que você fez é usar o cruftpacote e excluir os arquivos encontrados /binou /usr/binque não provêm de um pacote:

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

   a menos que os arquivos sejam links simbólicos para arquivos /etc/alternatives(nesse caso, você deve deixá-los em paz).

Pode ser educativo explicar exatamente por que seu sistema está, em maior ou menor grau, "quebrado".

1. Como o @ basile-starynkevitch aponta, o sistema de gerenciamento de pacotes tem o potencial de ficar terrivelmente confuso se encontrar binários /binquando eles devem estar /usr/bine vice-versa.
2. Alguns scripts (possivelmente importantes) podem ser conectados para encontrar um binário específico em um diretório ou outro (em algumas circunstâncias, é uma boa prática, por exemplo, do ponto de vista da segurança, não confiar no conteúdo do $PATH).
3. A razão pela qual existe uma distinção entre /bine /usr/biné que a primeira pode estar em uma partição montada em um estágio anterior da inicialização. Nesse contexto (ou seja, ao inicializar o sistema), não apenas os /bin/xxxbinários provavelmente seriam referidos por um caminho completo, mas o diretório /usr/binpode não estar disponível no sistema nesse momento. (Se você df /bine df /usr/bin, você pode ver o mesmo sistema de arquivos listado ou diferentes; provavelmente a maioria das instalações padrão hoje em dia, deixa os dois diretórios na mesma partição).

Assim, você pode dobrar de vista que, se você tiver os mesmos binários em ambos /bine /usr/bin, os problemas 2 e 3 não ocorrerão e o dano de 1 poderá ser menor. Re 1, por exemplo, os pacotes podem não ser desinstalados corretamente se você tentar removê-los; e as atualizações podem ficar distorcidas, se a atualização tentar atualizar a cópia no local 'correto', mas ignora a cópia no local 'errado'. Portanto, se os remédios acima parecerem muito drásticos ou complicados, você poderá deixar o sistema nesse estado.

Mas se esse for um sistema importante, eu realmente não apostaria nisso.

A regra geral (mais uma vez ecoando @ Basile-starynkevitch) é nunca macaco com /usr/bin, /bine amigos - eles 'pertencem' para a distribuição - e um pacote que sugere fazê-lo como parte de sua instalação normal é ... não é um pacote bom.

Edit: Relevante ao ponto 3, há uma discussão no contexto do systemd / Fedora e amigos sobre por que faz sentido mover todo o conteúdo de /binpara /usr/bine vincular o primeiro ao segundo. Isso é não uma recomendação que você fizer isso, você mesmo - essa página é dirigido a pessoas que fazem distribuições - mas inclui alguma história de por que existe esta distinção (e, por implicação, por isso agora é tradição meramente empoeirado).