Por que isso está acontecendo?
$ sudo ls /var/lib/postgresql/9.4/pg_log/
postgresql-2015-03-23_134626.log postgresql-2015-03-25_000000.log postgresql-2015-03-25_095920.log
postgresql-2015-03-24_000000.log postgresql-2015-03-25_095626.log
$ sudo ls /var/lib/postgresql/9.4/pg_log/*
ls: cannot access /var/lib/postgresql/9.4/pg_log/*: No such file or directory
ls /path/to/dir/ mostra arquivos, mas ls /path/to/dir/* diz que nenhum arquivo foi encontrado.
Por que isso acontece?
O curinga é expandido pelo shell antes que o sudo seja executado. O usuário atual não pode acessar os arquivos, portanto, a string é passada literalmente para sudo e, posteriormente, ls . ls não expande curingas (é o dever do shell), por isso não pode encontrar o arquivo chamado * .
Proteja o curinga citando e chame um shell raiz para expandi-lo:
sudo sh -c 'ls /var/lib/postgresql/9.4/pg_log/*'
Você está enfrentando um aspecto do problema discutido
sudo não foi possível gravar em /etc/profile
e Como anexar um arquivo como sudo ? ,
e o problema discutido em Quem lida com o * em echo * ?
Seu shell principal interpreta cada comando digitado,
incluindo caracteres curinga (também conhecidos como globs ou padrões de nome de arquivo). Se você digitar
some_command *
o shell enumera os arquivos no diretório atual e passa-os ao comando; por exemplo,
some_command black blue brown green orange red white yellow
Bem, se você não tiver permissão para ler /var/lib/postgresql/9.4/pg_log ,
então sua concha
não tem permissão para enumerar /var/lib/postgresql/9.4/pg_log/* .
O fato de que, quando o comando é executado , ele é executado como root , é muito pouco,
tarde demais - a expansão do nome do caminho (ou seja, interpretação de curinga) é feita até então.
Você pode corrigir isso com um truque discutido nas duas primeiras perguntas que mencionei:
sudo sh -c "ls /var/lib/postgresql/9.4/pg_log/*"
Isso executa um shell privilegiado. O shell privilegiado pode então expandir o * .
Tags linux