Qual é a função do asterisco como um comando independente no Unix?

Eu estava brincando no terminal do Red Hat Linux e, quando digitei o asterisk ( *) seguido de retorno, ele executou um dos programas no meu diretório. Por quê?

Meu melhor palpite é que o Unix o tratou como um curinga, por isso executou o primeiro programa alfabético. Como my_program.exee one_of_my_programs.programpode ser executado simplesmente digitando o nome do arquivo, o operador curinga representa todos os arquivos possíveis. Como um programa é o primeiro em ordem alfabética, o Unix o executa. Este é um julgamento correto?

— user6086585
fonte

Acho que nem todas as conchas classificam a expansão *alfabeticamente, mas o bash é o que faz.

— aschepler

@ aschepler: todos os reservatórios em conformidade com POSIX devem; veja pubs.opengroup.org/onlinepubs/9699919799/utilities/... para 3.

— dave_thompson_085

Respostas:

Sua interpretação está correta. O restante dos arquivos será apresentado como sua lista de parâmetros.

Observe que isso será feito apenas se o programa tiver o bit executável definido e o diretório atual estiver na PATHlista.

Algumas notas que podem ajudar a entender: -

Se você digitar ./*, a PATHentrada não é um requisito.
Se você digitar . *ou . ./*e o primeiro arquivo correspondente for um script, ele não precisará ser executável nem o diretório atual estar PATH(pode não ser verdade para shells que não sejam bash).

— AFH
fonte

"ele fará isso apenas ..." - Pode ser mais interessante. Se houver uma função shell, builtin ou um executável anteriormente PATHcom o mesmo nome que o primeiro arquivo, esse outro comando será executado. mkdir foo; cd foo; touch rm xyz; ls; *; ls.

— Kamil Maciorowski

@KamilMaciorowski - Ponto justo: minha afirmação "ele fará isso apenas ..." especificou as condições necessárias , mas não as suficientes . O comando também se comportará de maneira diferente se *for um alias.

— AFH

Conclusão: não faça isso! Mesmo que você pense que pode confiar na ordem alfabética da expansão glob, observe que essa ordem depende do código do idioma.

— Aaron

além de . *ou . ./*uma lata bash *(ou qualquer outra concha).

— Olivier Dulac 05/10

Isso sugere que .faz parte da sua PATHvariável. Essa é uma péssima idéia por razões de segurança (naturalmente, o Windows precisava torná-lo um padrão não modificável).

No entanto, essa "sugestão" é apenas levemente válida: se você tiver um arquivo nomeado rmem seu diretório atual, *executará o padrão rm :

/tmp$ mkdir ohno
/tmp$ cd ohno
/tmp/ohno$ 
/tmp/ohno$ ls
/tmp/ohno$ touch rm what
/tmp/ohno$ ls
rm  what
/tmp/ohno$ *
/tmp/ohno$ ls
rm
/tmp/ohno$

Como você pode ver, não estava rmno diretório atual (um arquivo vazio e não executável) que foi executado, mas sim no padrão do sistema /bin/rm.

Sempre verifique seus comandos quando houver caracteres curinga. Aqui está uma das mensagens mais aterradoras já lidas:

rm: cannot remove '.o': No such file or directory

Este é o resultado de chamar

rm * .o

, mais ou menos o pior posicionamento de um espaço falso que se pode imaginar.

Não é necessário criar uma função rm()que adicione -iparâmetros ou verifique os parâmetros e solicite confirmação se houver mais de um determinado número.

— AFH 04/10

+1 em "Aqui está uma das mensagens mais aterrorizantes que você já leu".

— Mehrdad 5/10

+1 em "Essa é uma péssima idéia por motivos de segurança (naturalmente, o Windows precisava torná-lo um padrão inalterável)".

— Duncan X Simpson

FTFY: mv /tmp/ohno /tmp/ohnoes( google.fr/search?q=ohnoes&source=lnms&tbm=isch )

— Olivier Dulac

Há uma boa razão pela qual o Windows o tornou um padrão não modificável. Ele precisa manter uma cadeia de compatibilidade com versões anteriores dos dias anteriores aos diretórios implementados pelo DOS. Lembre-se daqueles dias em que ninguém que usava um PC tinha um disco rígido, e os disquetes eram pequenos o suficiente para que os diretórios não fossem inicialmente considerados necessários.

— Muzer #