Não é possível listar o diretório de dentro, apenas de fora

Question

Eu tenho um diretório com três subpastas onde construí um cross gcc. Portanto, existem os diretórios binutils , gcc e glibc que são apenas os diretórios de construção, as origens correspondentes estão em diretórios diferentes. Tudo correu bem, eu compilei e instalei tudo em algum caminho personalizado.

Quando eu tento inserir o subdiretório glibc (da minha árvore de compilação) não consigo listar o conteúdo, recebo uma mensagem de erro que não é legível:

$ ls
ls: �����: ��dJ: Error 1673445588re

Se eu fizer isso novamente, outro número de erro será exibido:

$ ls
ls: �vP��: ��u: Error 3137748

Ou um arquivo concreto:

 $ ls config.status
 ls: : ���s: Error 123785428

Se eu listar o conteúdo de uma hierarquia acima, funciona:

 $ ls glibc
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map
 ...

Se eu me tornar root e entrar no diretório, também posso listá-lo:

 # ls 
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map
 ...

A pasta em si:

 $ ls -lh glibc -d
 drwxr-xr-x 63 david david 4.0K 17. Aug 16:30 glibc

Proprietário correto, permissões corretas.

eu já corri

  # e2fsck -pfc /dev/sdb4

Nenhuma alteração.

Não há erro em nenhum arquivo de log, dmesg não mostra nenhum erro, a verificação do sistema de arquivos não relatou nenhum erro, o que pode ser isso?

Atualizar

O fato de que eu estava criando um cross gcc leva a supor que meu ambiente é afetado por essas bibliotecas ou binários. Durante a compilação cruzada ou durante a compilação do cross gcc, eu realmente ajustei o caminho para o shell com o qual eu construí o ambiente e apontei para o caminho de instalação do cross gcc. Mas o gcc não fornece /bin/ls ou algo parecido, também meu LD_LIBRARY_PATH e similares não são definidos. O comando ls vem do meu sistema:

$ where ls
ls: aliased to ls --color=always
/bin/ls
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffea1362000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc18b429000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc18b7c2000)

Todo o resto (parece) funcionar bem, eu não tenho nenhum outro problema com o meu sistema ou com este SSD (Samsung SSD 840 EVO 500 GB, EXT0DB6Q). Após várias reinicializações, o problema permanece.

O que eu não percebi até agora - se eu estiver dentro desse diretório, o comando EVERY ls falhará, eu nem posso mais listar meu diretório pessoal:

$ ls ~
ls: ���e�: �i"�5: Error 18446744071861719252

Saída diferente toda vez:

$ ls ~
ls: Pg��: ��{
: Error 2070020308

~/cross-build/inc100/glibc # this is the path to this directory
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-
bin/5.4.0:/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-
bin/6.4.0:/home/david/usr/bin

Hm:

~/cross-build/inc100/
$ ls glibc
.... libc.so libc.so.6

Se eu mover o arquivo libc.so para algo como libc.so.backup de um diretório acima e, em seguida, entrar no diretório, funcionará!

Parece que o linker encontra este libc.so neste diretório e simplesmente o usa? Mas por que o eco funciona e não é? find também se comporta errado. E como posso evitar esse comportamento?

Atualizar echo funciona porque é um shell embutido, ls , find etc. são binários vinculados a libc.so , essa é a razão para o comportamento diferente.

Eu ainda não sei por que isso acontece e como posso evitá-lo, eu realmente não quero esse comportamento de "janela-ish".

    

Answer 1

Talvez o seu comando ls não seja /bin/ls ?. Tente verificar se ls é realmente /bin/ls em todos os diretórios com o comando:

which ls

Eu assumi que há um arquivo executável chamado ls nesse diretório, e sua variável de ambiente $PATH executou esse comando em vez de /bin/ls .