Eu teria feito um comentário sobre a resposta de Marki , mas teria sido muito longo. Há uma ressalva em sua solução:
A análise de saída de ls
ou find
é igualmente não robusta e passível de quebra . Aqui está um exemplo:
$ mkdir dir{1,2}
$ touch !$/file{1..5}
touch dir{1,2}/file{1..5}
$ mkdir dir1/$'\n'.
$ touch !$/whoops
touch dir1/$'\n'./whoops
$ touch dir2/whoops
$ touch dir1/onlyin1
$ touch dir2/onlyin2
$ comm <( cd dir1 ; find . | sort ) <( cd dir2 ; find . | sort )
.
.
./
./
./file1
./file2
./file3
./file4
./file5
./onlyin1
./onlyin2
./whoops
(Estou usando comm
para comparação de texto de três direções, em vez de vimdiff
, para copiar e colar mais facilmente; o resultado é o mesmo em vimdiff
.)
Você verá que isso exibe incorretamente que o arquivo whoops
está em ambos os diretórios, quando, na verdade, um desses arquivos whoops
está em um subdiretório de dir1
que contém uma nova linha em seu nome.
Normalmente, as pessoas não colocam novas linhas em nomes de arquivos ou diretórios, e a vimdiff
answer deve funcionar em qualquer outro caractere especial (embora eu não tenha testado). No entanto, ainda é algo para ser cauteloso. Se você pretende colocar isso em um script ou em um código de produção de qualquer tipo, por favor, trabalhe para torná-lo mais robusto, por exemplo, caminhando as árvores de diretórios corretamente e comparando-as.