A sintaxe a*
e *a*
é implementada pelo shell, não pelo ls
comando.
Quando você digita
ls a*
no prompt do shell, o shell se expande a*
para uma lista de todos os arquivos existentes no diretório atual cujos nomes começam com a
. Por exemplo, ele pode se expandir a*
para a sequência a1 a2 a3
e passar esses argumentos para ls
. O ls
comando em si nunca vê o *
personagem; ele só vê os três argumentos a1
, a2
e a3
.
Para fins de expansão de curinga, "arquivos" refere-se a todas as entidades no diretório atual. Por exemplo, a1
pode ser um arquivo normal, a2
um diretório e a3
um link simbólico. Todos eles têm entradas de diretório e a expansão de curinga do shell não se importa com o tipo de entidade a que essas entradas se referem.
Praticamente todos os shells com os quais você provavelmente encontrará (bash, sh, ksh, zsh, csh, tcsh, ...) implementam curingas. Os detalhes podem variar, mas a sintaxe básica de *
corresponder zero ou mais caracteres e ?
qualquer caractere único é razoavelmente consistente.
Para o bash, em particular, isso está documentado na seção "Expansão do nome do arquivo" do manual do bash; execute info bash
e procure por "expansão de nome de arquivo" ou veja aqui .
O fato de isso ser feito pelo shell, e não por comandos individuais, tem algumas conseqüências interessantes (e às vezes surpreendentes). A melhor coisa é que o manuseio de curinga é consistente para (quase) todos os comandos; se o shell não fizesse isso, inevitavelmente alguns comandos não se incomodariam e outros o fariam de maneiras sutilmente diferentes que o autor pensava serem "melhores". (Acho que o shell de comando do Windows tem esse problema, mas não estou familiarizado o suficiente para comentar mais.)
Por outro lado, é difícil escrever um comando para renomear vários arquivos. Se você escrever:
mv *.log *.log.bak
provavelmente falhará, pois *.log.bak
é expandido com base nos arquivos que já existem no diretório atual. Existem comandos que fazem esse tipo de coisa, mas eles precisam usar sua própria sintaxe para especificar como os arquivos serão renomeados. Alguns comandos (como find
) podem fazer sua própria expansão de curinga; você precisa citar os argumentos para suprimir a expansão do shell:
find . -name '*.txt' -print
A expansão do curinga do shell se baseia inteiramente na sintaxe do argumento da linha de comando e no conjunto de arquivos existentes. Não pode ser afetado pelo significado do comando. Por exemplo, se você deseja mover todos os .log
arquivos para o diretório pai, pode digitar:
mv *.log ..
Se você esquecer o ..
:
mv *.log
e houver exatamente dois .log
arquivos no diretório atual, ele será expandido para:
mv one.log two.log
que irá renomear one.log
e derrotar two.log
.
EDIT : E depois de 52 votos positivos, um aceito e um distintivo de Guru, talvez eu deva realmente responder à pergunta no título.
A opção -d
ou não indica para listar apenas diretórios. Ele diz para listar diretórios da mesma forma que eles, não seu conteúdo. Se você fornecer um nome de diretório como argumento , por padrão, ele listará o conteúdo do diretório, já que geralmente é disso que você está interessado. A opção diz para ele listar apenas o próprio diretório. Isso pode ser particularmente útil quando combinado com caracteres curinga. Se você digitar:--directory
ls
ls
-d
ls -l a*
ls
fornecerá uma lista longa de cada arquivo cujo nome começa com a
e do conteúdo de cada diretório cujo nome começa com a
. Se você deseja apenas uma lista dos arquivos e diretórios, uma linha para cada, você pode usar:
ls -ld a*
que é equivalente a:
ls -l -d a*
Lembre-se novamente que o ls
comando nunca vê o *
personagem.
Quanto a onde isso está documentado, man ls
mostrará a documentação para o ls
comando em praticamente qualquer sistema semelhante ao Unix. Na maioria dos sistemas baseados em Linux, o ls
comando faz parte do pacote GNU coreutils; se você possui o info
comando, info ls
ou info coreutils ls
deve fornecer uma documentação mais definitiva e abrangente. Outros sistemas, como o MacOS, podem usar versões diferentes do ls
comando e podem não ter o info
comando; para esses sistemas, use man ls
. E ls --help
mostrará uma mensagem de uso relativamente curta (117 linhas no meu sistema) se você estiver usando a implementação do coreUtil GNU.
E sim, mesmo os especialistas precisam consultar a documentação de vez em quando. Veja também esta piada clássica .